What are the types of these Stakeholders who are so scary to influence the project success or failure?
- Sponsor: a project sponsor is typically a senior executive either from program or department in your organization. Just think of a person with the MONEY who is willing to take risk on the project future. Sponsors assign the Project Managers and authorize to start the project! Envision – an executive with project charter on one hand and money on another. Taking risk of project failure should be his/her habit. Whenever you see such a person in your team- you know now who this confident man/women is?
- Vendor/Partners: Mostly the external parties who are in relationship with the project either due to contracts, agreements, bids, SLAs or work Orders. In most -cases they sell services or goods to the project. These people normally help you understand the product features of the solution (business functional & quality requirements) if they are selling the goods. If they are selling the services then they are critical on the project processes & tasks – ultimately responsible for the project requirements. DO YOU KNOW DIFFERENCE BETWEEN BUSINESS REQUIREMENTS AND PROJECT REQUIREMENTS? Letting you brainstorm a bit! While you are thinking – think also about the buyers & their impact (not the sellers as stated above)
- Project Team: the project manager is the person who was authorized (mostly by the project sponsor) to manage a project. The project manager’s and business analyst job is to identify all other stakeholders as early as possible determine their role, responsibility, impact, influence.
- These may be:
- Project Manager (also Sponsor)
- Business Owner (executive or director level)
- Technology Owner (executive or director level)
- Business Analyst, System/Solution Analysts (may be combined as one role)
- Lead Engineers & Engineers
- Quality Assurance Analysts & their leads
- User Acceptance Testing Manager/Lead & UAT Testers
- Others – Vendor Project Team Members, External Team Members, etc
- These may be:
- Requirements Stakeholders/Owners – You already know about them from the last post. If not yet then re-visit the post again.
Is the Business Analysts (or Lead BA/BSA or PM) the owner of requirements or is it someone else who “owns the requirement(s)”? If you thought “BA as owner” then note- you have a long way to go before you become a Professional Business Analyst (not talking about Lead BA/BSA- it is even farther away).
BA/BSA simply owns the requirement document- The ARTIFACT, not the requirements which are listed inside that document. You, as a BA/BSA, are simply the author not the owner. Owner of each requirement is generally the accountable (sometimes responsible) person who provided you that requirement(s). That is the reason why we ask for their hard approval at the end.
Few BA/BSAs make one most regretful mistake during their assignment, especially when they are new- they think themselves as the owner (or a solution finder) while gathering requirements and then document their ideas as the requirement. Remember – Business Analysts are not allowed to write requirement or solutions out of their head- it should be given to you by the requirements owners and better analysed before jotting them down to your formal artifacts. BA/BSAs are not the owners of business requirements.
Few more items for you to Brainstorm on: what are the differences between BA role, Enterprise BA role, BSA role and IT BA or Technology BA role (not talking about Lead)? Add one more thought wave to your storming brain – Does BA approve artifacts (example – BRD or FRD) that they authored? In other words- is the author approver of any project artifact? Why? (Hint- look at the paragraph above)
- Customer/Users/End-Users (future or past): customers or users are persons or organizations that use the product or service created by a project.
Leaving few important questions for you to evaluate–
Are stakeholder requirements same as User Requirements? Are they part of business requirements or business requirement is part of User Requirement? What about project requirement then? You don’t have to answer these questions online – they are just meant for you to think and research around ….
If I get enough time to create other posts then I will bring up new topics on “Most Effective Ways Of Identifying User Stories”, “Their Relationship To Business Requirements” , “Their Use in Agile /Adoptive Methodology” and “Do They worth the Hype (Answer Hint –No)?”
QUESTION- Can they be the past users? Yes- all the users who once used its previous version or all those who will use the future version for the enhancement projects (not brand new projects) are considered users of the product. User requirements mostly come from these users. Have you ever heard of User Stories? Yep – that’s it. User stories are higher level User Requirements (mostly said Business User Stories) which gets broken down into solutions and use cases.