We use Stakeholder Analysis to identify people who have a stake in our product. Then we classify those stakeholders to figure out:
- How to weight their input at various stages.
- When and how to keep them informed.
When do We Use Stakeholder Analysis?
We use stakeholder analysis before we start planning a project. Why? Because we need to know who we need to be talking to and what we’ll need from them. Until we have that, we can’t create an effective plan. And we also need to plan our output. This affects what we’ll put into updates and when.
What is a Stakeholder?
A stakeholder is someone who:
- Will have input into the product. These are generally internal people, but not always. These could include:
- Subject matter experts
- Product owners
- Technical writers
- Quality assurance.
- Will use the output of the product. These are usually external people. These could include:
- End users
- Target audience.
How do you Identify Stakeholders?
Look at the various aspects of your project. For example, you could split the project into the following categories:
- Customer support
Then, identify people who are involved in those categories. For example, a software project might look like this:
|Category||Internal stakeholders||External stakeholders|
|Marketing||Marketing department||Target market|
|Sales||Sales department||Potential customers|
|Customer support||Customer success team||Customers|
Quality Assurance team
|External project partners|
Make sure you consider people who are:
- Financing the project.
- Benefiting from the project (SIPOC can help here).
- Executing the project.
- Affecting the project.
What is a Stakeholder Map?
A stakeholder map is a way to group and prioritize people. It’s based on a couple of key aspects:
- How much power they have.
- How much interest they have.
A person with power can affect the direction of the project.
A person with interest cares about the outcomes of the project.
A basic stakeholder map looks like this:
This stakeholder map uses two levels of power and interest. You can use more, if needed. Only do this to fine tune your mapping.
Tools to Help Identify Stakeholders
Before you can add stakeholders to the map, you must identify them.
The obvious answer to ‘who makes decisions?’ might seem to be, ‘the CEO!’ . Chances are, though, that this person isn’t making decisions in a vacuum. That would be a very inefficient way to operate.
Most decision makers have people around them to help. These people:
- curate information.
- condense large numbers of options into the three or four most likely candidates.
All of these helpers are involved in the decision making process. As such, they have substantial influence on it.
The RAPID model helps you to classify and identify these people. Not just those who make decisions. Also those who contribute to decision making in an organization. It was developed and trademarked by Bain & Company.
It includes five key roles:
The Recommend role
The Recommender is someone who has a good overall knowledge. They understand the subject of the decision. They:
- Gather information.
- Condense it into brief points for easy reading.
- Make suggestions based on it.
For example, a company might be building software. It has to work out which cloud provider to use for this task. The CTO brings in the architect. This person has a decent working knowledge of all the big cloud platforms. They deliver a report detailing the pros and cons of each. Then they suggest one provider based on their knowledge of the software to be built.
The Agree role
The Agreer is complementary to the Recommender. They might not be an expert, but they have a decent level of knowledge. They don’t gather or condense data. Instead, they work with the Recommender to support the suggestion. This might involve compromise to gain accord.
For example, the architect reports to the CTO. The CTO takes the Agree role here. The architect must convince the CTO of the suggested option. Only then will the CTO take the report to the other C-level execs.
The Perform role
The Performer is a person who’ll turn the decision into reality. This is usually a team; more than one person. They take the decision and carry it out.
For example, in our cloud software decision, the Performer could be coders and designers. They’ll turn an abstract decision into reality. They’ll use the platform to create a product.
The Input role
The Inputter provides information. This might be given to the Recommender or the Decider. The Inputter doesn’t make suggestions. Instead, they just provide the data. Someone else can use that to propose a course of action.
For example, an Inputter might have training in cloud coding. They know best practices and have useful info to offer.
The Decide role
The Decider takes the data and proposals given by people in other roles. Then they make a final decision. They are accountable for the decision. They are also responsible for ensuring that they follow through.
For example, a Decider could be a CEO or CTO. They have control of at least one team. They decide how and what the team should work on.
These models identify people involved in tasks.
Basic RACI model
In the basic RACI model, there are four roles people can take in tasks. The roles are:
RACI charts clearly show:
- Who is involved in a task.
- What their role is.
The Responsible role
This is the person doing the task. For example, a coder creating a specific feature.
The Accountable role
This is the person overseeing the Responsible person. For example, a team leader.
The Consulted role
This is the person who can provide help and info. For example, a system architect.
The Informed role
This is the person who needs to be kept up to date on progress of the task. For example, the user who requested the feature.
Other Responsibility Assignment models
There are a lot of variations on the RACI theme. They include different naming and application of the four roles. Some have more or less than the RACI model. You can see a good list of these on Wikipedia.
Where Would You Use Stakeholder Analysis?
Use this analysis when you’re putting together :
- Project Charter
- Communication Plan
- Pilot Plan
- Control Plan
- Critical to Quality (CTQs)
- Risk Analysis
Example of Stakeholder Analysis for a DMAIC Project
A company offers a customer support phone line. It wants to improve the quality of its support. It also wants to decrease customer wait times. Before starting the project, the team in charge needs to do a stakeholder analysis. They’ll identify people who have an interest in the project. Then they’ll know who to consult and inform at each step.
The first task that the team need to complete is to identify its stakeholders. The team members decide to brainstorm. They gather a list of every person who might influence or be affected by the project.
The team now has a list of stakeholders. The next step is to map those people using a basic stakeholder matrix.
|Other teams|| Developer team|
Customer service team
After the mapping
Now that they’ve mapped out the stakeholders, the team know who to:
- Keep satisfied (Latents).
- Manage closely (Promoters).
- Monitor (Apathetics).
- Keep informed (Defenders).