Stakeholder Analysis: How to Map and Manage Stakeholders

Projects rarely fail because the code was bad. They fail because a senior person who nobody talked to decided, late in the day, that they hated the plan. A stakeholder analysis is how you find that person early, while there's still time to listen to them.

This guide walks through the process step by step, with a power and interest grid and a worked example, plus practical tips for keeping people on board once you've mapped them.

What is stakeholder analysis?

Stakeholder analysis is the process of identifying the people and groups who have a stake in your project, assessing how much influence and interest they have, and planning how to communicate with and involve each one. A stakeholder can be anyone: a sponsor, a customer, a team member, a regulator, a department that will lose a system you're replacing.

The goal isn't a pretty chart. It's to avoid surprises and to spend your limited time on the right people.

Step 1: identify your stakeholders

Brainstorm widely. A good prompt is to walk through the project's life and ask who it touches at each stage. Here's a starting list to jog your memory:

• Sponsor and senior leaders

• Customers and end users

• The project team and their managers

• Other teams that depend on your work

• Suppliers and partners

• Finance, legal, security and compliance

• Support and operations teams who'll run the result

Don't filter yet. Write everything down, and sort it out in the next step.

Step 2: assess power and interest

For each person or group, ask two questions. How much power do they have over the project, through budget, authority or the ability to block it? And how interested are they in the outcome? Rate each as high or low. A simple conversation with the team usually does the job.

Step 3: place them on a power and interest grid

The grid, sometimes called Mendelow's matrix, sorts stakeholders into four boxes.

The top right box deserves most of your attention. These people can make or break the project, and they care about it.

A worked example: a customer portal project

Notice the legal team. They look unimportant until the week before launch, when they can stop everything. That's why you ask about power and not just interest.

Step 4: look at attitude as well

The grid doesn't tell you whether someone supports you. Add a column for how each person feels: supportive, neutral or resistant. A powerful, resistant stakeholder needs a very different approach from a powerful supporter.

Try to understand why. Resistance usually has a reason. They might fear losing control, worry about extra work or doubt that the plan can succeed. Listening often turns out to be the cheapest tool you have.

Step 5: plan how you'll engage each group

• What do they need to know, and how often?

• What do we need from them?

• What's the best channel, such as a meeting, email or a dashboard?

• Who on our team owns the relationship?

Put owners next to names. If "the team" is responsible for talking to the finance director, nobody is. Our free RACI matrix template can help you spell out who is responsible, accountable, consulted and informed.

Questions to ask each stakeholder

Analysis on paper only goes so far. A short conversation with the important ones tells you more than a day of guessing. These questions usually do the trick:

• What would a successful result look like for you?

• What worries you most about this project?

• How would you like to hear about progress, and how often?

• Who else should I be talking to?

• Is there anything that would make you withdraw your support?

What to put in a stakeholder register

Dealing with a resistant stakeholder

Start by asking why. Often it turns out they have a perfectly sensible worry, like a team losing a tool they rely on, and you can address it. Involve them early, give them a real say in some decisions and keep your promises on small things. Trust builds quickly when people see you do what you say.

If they stay opposed, don't ignore them. Make sure your sponsor knows, and decide together how to proceed. A known disagreement is manageable. A hidden one is a time bomb.

A second example: an internal tool rollout

Stakeholder analysis isn't only for customer facing products. Suppose a company is rolling out a new expense tool. The finance team has high power and high interest, because it changes how they work. Employees have low power but high interest, since they'll use it every week. IT has high power and moderate interest, because security approval is theirs. The CEO has high power and low interest, as long as costs stay in line.

Even this quick sketch shows what to do. Involve finance in the design, run demos for employees, get IT's security review done early and send the CEO a short monthly summary. Four groups, four different plans, all from ten minutes of thinking.

Watching for hidden stakeholders

Some people never appear on the org chart but still matter, like the long serving administrator who knows how things really work, or the team lead whose people will absorb the extra workload. Ask "who else will this affect?" in every conversation, and you'll find them.

Step 6: review it regularly

Stakeholders change. People change jobs, priorities shift and a quiet observer suddenly becomes a worried sponsor. Revisit the analysis every month or at each project phase, and update it whenever something big happens.

Communicating with each group

Match the format to the person. A busy director might prefer a five line email, while a user group may enjoy a live demo. Ask them, then do what they say.

Keeping a record of conversations

Write down what you've agreed with important stakeholders, and send a short summary afterwards. It prevents misunderstandings and gives you something to point to if memories differ later.

Stakeholder analysis and the project manager's job

Managing stakeholders is as much people work as paperwork. It rewards listening, honest updates and a bit of courage when the news isn't good. If you're building these skills, our piece on how to become a good project manager is worth reading.

On larger efforts that span several projects, stakeholders overlap and compete for attention. That's where program management comes in. You can see how program management works in Sanplex when you coordinate many projects with shared stakeholders.

Mistakes to avoid

Doing it once and filing it

A stakeholder map from month one is probably wrong by month four.

Only talking to the friendly ones

It's comfortable to update your supporters. The people who worry you need the attention more.

Writing sensitive opinions where everyone can read them

Notes like "resistant" or "difficult" are useful, but keep the document private to the project leadership.

Treating all stakeholders alike

Sending the same long update to everyone means the people who need detail don't get it and the rest stop reading.

Frequently asked questions

What is stakeholder analysis?

It's the process of identifying everyone with a stake in a project, assessing their power, interest and attitude, and planning how to engage each one.

What is a power and interest grid?

It's a four box chart that sorts stakeholders by their power over the project and their interest in it, into manage closely, keep satisfied, keep informed and monitor.

How often should I update a stakeholder analysis?

Monthly, or at each project phase. Also update it whenever there's a significant change, such as a new sponsor or a change of scope.

Who should be on a stakeholder list?

Anyone who can affect the project or is affected by it, including sponsors, users, team members, other departments, suppliers and regulators.

What is the difference between a stakeholder analysis and a RACI matrix?

A stakeholder analysis explores who has power, interest and what attitude. A RACI matrix assigns roles for tasks or decisions. They work well together.