We use Stakeholder Analysis to identify people who have a stake in our product. Then we classify those stakeholders to figure out the following:

• How to weigh 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:
  • Investors
  • Subject matter experts
  • Analysts
  • Architects
  • Developers
  • Marketers
  • Product owners
  • Technical writers
  • Testers
  • Quality assurance.
• Will use the output of the product. These are usually external people. These could include:
  • Customers
  • 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:

• Marketing
• Sales
• Customer support
• Design
• Implementation
• Testing/QA
• Documentation
• Financing
• Oversight.

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
Design	Product Owner Product Architect UX Graphic designer	End users
Implementation	Product Owner Developers
Testing/QA	Testing team Quality Assurance team	Beta users
Documentation	Technical writer UX team	End users
Financing	Company board Accounting department	External project partners Investors
Oversight	Upper management CTO	Auditors Regulators

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 do they have?
• How much interest do 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.

RAPID Model

The obvious answer to ‘Who makes decisions?’ might seem to be, ‘the CEO!’. Chances are 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 a substantial influence on it.

The RAPID model helps you to classify and identify these people, not just those who make decisions. This model also identifies those who contribute to decision-making in an organization. It was developed and trademarked by Bain & Company.

The RAPID model includes five key roles:

• Recommend
• Agree
• Perform
• Input
• Decide.

The Recommend role

The Recommender is someone who has 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 decent 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.

Responsibility Assignment

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:

• Responsible
• Accountable
• Consulted
• Informed.

RACI charts clearly show:

• Who is involved in a task?
• What is their role?

The Responsible role

This is the person doing the task. For example, a coder creates 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 the 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
• SIPOC
• Communication Plan
• Pilot Plan
• Control Plan
• FMEA
• 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.

Identifying stakeholders

The first task that the team needs 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.

Mapping stakeholders

The team now has a list of stakeholders. The next step is to map those people using a basic stakeholder matrix.

Power→	Latents	Promoters
	Customers Investors	CEO CTO
	Apathetics	Defenders
	Other teams	Developer team Customer service team
	Interest→

After the mapping

Now that they’ve mapped out the stakeholders, the team knows who to:

• Keep satisfied (Latents).
• Manage closely (Promoters).
• Monitor (Apathetics).
• Keep informed (Defenders).