Scary stakeholders influence the project future! What ?

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 thinks 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 are important to understand the product feature of the solution (business requirement) if they are selling the goods. If they are selling the services then they are critical on the project process/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:

1.       Project Manager (also Sponsor)

2.       Business Owner (executive or director level)

3.       Technology Owner  (executive or director level)

4.       Business Analyst, System/Solution Analysts (may be combined as one role)

5.       Lead Engineers & Engineers

6.       Quality Assurance Analysts & their leads

7.       User Acceptance Testing Manager/Lead & UAT Testers

8.       Others – Vendor Project Team Members, External Team Members, etc

• Requirements Stakeholders/Owners – You already know about them from the last post. If not yet then visit the post again.

CAN YOU ANSWER A MOST IMPORTANT QUESTION ALL EXPERIENCED PM OR BA KNOWS? Is the Business Analysts (or Lead BA/BSA or PM) the owner of requirements or is it someone else who owns the requirement? If you thought BA as owner then note you have a long way to go before you become a True Professional Business Analyst (not talking about Lead BA/BSA it is even farther away).
BA/BSA simply owns the requirement document not the requirements which are listed inside that document.  You are simply the author not the owner. Owner of each requirement is generally the accountable (sometimes responsible) person who provided you that requirement. That is the reason why we ask for their hard approval at the end.
Brainstorm again – 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.

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.

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)?”

Leaving you with few important questions – 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 ….