In Part 1 of this series, I explained why engaging project stakeholders matters. But it doesn’t matter how well you engage your stakeholders if you don’t know who they are. Taking the time to ensure you have all the right stakeholders involved at the right level of participation is what Stakeholder Analysis is all about.
Let’s start by defining what a “stakeholder” is.
A stakeholder is basically anyone who is going to care about your project.
This could mean that they are directly impacted (i.e. they will be involved in implementing a solution, or how they perform their job might change when the solution is rolled out); or they may have an interest in the solution (i.e. legal department to ensure the solution maintains compliance, or the mail room who may get increased mail volume due to a marketing campaign).
Stakeholder Analysis is the process you go through to determine who all the stakeholders are. I recommend this is an activity that you work on collaboratively with the project manager. You will each bring a slightly different perspective to thinking about who will need to be involved, and together you should come up with a pretty solid list. To get you started thinking about the possible stakeholders you might have, here are a few questions you might consider:
- What user(s) will be directly using the solution (new process or technology)? (These people are often referred to as the “end users”.)
- What people do the end users work with, get information from, or provide information to?
- What are all the systems currently used by the end users? Who uses those systems? Who maintains those systems?
- Are there any legal or regulatory items that need to be taken into consideration?
- Could there be changes to people’s roles and titles as a result of this effort? Do new job descriptions need to be written?
- Who will train the end users when the new solution is ready?
- Does anyone outside the company need to be notified about this project?
- Is this an opportunity to do any PR or Marketing?
Note: Your list at this point may only identify the stakeholder as a role (i.e. Legal Department) rather than an individual person, since you might not know exactly who will be available to represent that role for your project.
Once you have identified who the stakeholders are, you will want to identify what their responsibilities are, which will help to determine what they need to know and when. One very common technique for doing this is completing a RACI Matrix (pronounced “ray-see”). This is where you classify each stakeholder as having one or more of the following responsibilities:
- (R)esponsible – those that do the work
- (A)ccountable – the person who is ultimately the decision maker (there should be only one and it is often the Executive Sponsor)
- (C)onsulted – those that need to be consulted and may have input
- (I)nformed – those that just need to be notified
Your RACI Matrix will likely also include this breakdown by specific deliverable or task and an individual or role may have different responsibilities for each task. For example, the Business Analyst may be (R)esponbile for the Requirements Document, but only (C)onsulted on the Master Test Plan.
When Should You Perform Stakeholder Analysis?
Right up front, and all the time. You’ll want to spend time on this as soon as you are aware of a new project or effort. This way you can start to properly educate and engage the right people right from the very beginning. But this is not a one-time activity. As the project progresses, be watching for information that could indicate different people need to be aware or involved.
But since you’ve done this right up front, you now know who should be invited to the Project Kick Off, which is your first opportunity to lay the foundation for the requirements phase of the project. We’ll talk about this more in Part 3 of this series.
In the meantime, what other questions help jog your memory during Stakeholder Analysis? Is there a stakeholder that is commonly forgotten?