← Blog

Stakeholders · 11 min read

Stakeholder Mapping: Who Can Make or Break Your Project

Every project has people who can help it, block it or quietly ignore it. A simple power and interest map shows who they are and how to work with each.

A project team standing at a glass wall with a four-quadrant grid made of tape and colored sticky notes in a bright modern office
A grid of tape and sticky notes is all it takes to see who matters to your project.

Picture a project that looks perfect on paper. The budget is approved, the schedule is realistic, the team is skilled and the technical design is sound. Then, three weeks before launch, a person nobody had thought about, perhaps an inspector, a neighbor, a department head whose staff would have to change how they work, says no. Or does not say anything at all and simply does not cooperate. The project stalls, the team is stunned and someone says the sentence every project manager has heard: "We should have talked to them earlier."

That sentence is the whole reason stakeholder management exists. Projects are not delivered by plans. They are delivered through people, and many of those people are outside the team and outside your control. The good news is that the discipline of understanding them is simple, takes only a few hours at the start and pays back many times over. This article walks through it step by step, with a short interactive tool at the end of the process so that you can try it on your own project.

What a stakeholder really is

A stakeholder is anyone who can affect your project or who will be affected by it. That definition is deliberately wide. It includes the obvious people, like the sponsor, the customers, the team and the suppliers. It also includes people who rarely show up in project documents: regulators and local authorities, the neighbors of a construction site, the staff who will inherit the result, partners, lenders, and sometimes even competitors.

The important word is "affect." Someone with no formal role can still have power over your project if they can delay a permit, spread an opinion or refuse to adopt the new way of working. And someone who is deeply affected, like the employees whose daily routine will change, may have little formal power but a great deal of ability to make a rollout succeed or quietly fail. Stakeholder management starts by taking both kinds seriously.

Step one: list everyone before you judge anyone

The first mistake is to start filtering too early. Someone says "the mayor will not care about this" and the name is crossed off before it is written. Instead, brainstorm freely for fifteen minutes with a few people who know the project, ideally including someone who has worked in the same environment before. Use categories as prompts:

  • People who pay, approve or sponsor the project.
  • People who use the result every day.
  • The team and the people who supply the team.
  • Suppliers, contractors and vendors.
  • Authorities and regulators: permits, inspections, taxes, environmental or safety bodies.
  • The community and neighbors.
  • Partners, lenders and investors.
  • Anyone who would lose something if the project succeeds.

Then ask the question that surfaces the hidden ones: "Who would be upset to hear about this from someone else?" The answers are almost always worth adding to the list.

On the large public works programs I have worked on, this list is long. Government agencies, supervisors, inspectors, subcontractors, labor representatives and local communities all have a role. A project that treats them as background noise pays later, in delays and in disputes. The same applies on a smaller scale. A restaurant opening has a health inspector, a landlord and neighbors who will hear the kitchen exhaust. A software launch has the customer support team who will receive the tickets. And an exploration project in the mining sector, such as Llama Purisima, depends on authorities, local landowners and communities as much as on geology.

Step two: map power and interest

Once the list exists, place each person on a simple grid. One axis measures power: how much ability does this person have to help or block the project? The other measures interest: how much does this person care about, or how strongly will they be affected by, the project? This is often called a power and interest grid, and it produces four groups.

  • High power, high interest: manage closely. These are your key players, such as the sponsor, the main client and the authority issuing a critical permit. They need frequent, personal engagement and a say in important decisions.
  • High power, low interest: keep satisfied. They can affect the project but do not follow it daily, for example a senior executive or a regulator. Give them concise updates and no surprises.
  • Low power, high interest: keep informed. They care a lot but cannot decide, like end users or neighbors. Communicate openly, listen and use their knowledge. They often spot problems early.
  • Low power, low interest: monitor. Do not ignore them, but do not spend time on them. Watch for changes in their position.

Do the mapping with the team in one sitting. Disagreements are valuable because they reveal different views of who matters. When two people place the same person in different boxes, ask why. The answer is often a piece of information the other person did not have.

Here is a tool to try it. Replace the sample names with the people in your own project, move the two sliders for each, and the tool will place them on the grid and tell you how to treat each one.

Interactive tool

Map your stakeholders

Loading the tool…

Step three: understand what each person wants

A grid tells you how much attention someone deserves. It does not tell you what to say. For the people in the top-right and top-left quadrants at least, take the time to understand their perspective. Two questions do most of the work: "What would make this a success for you?" and "What worries you about it?" Ask them directly when you can, and ask people who know them when you cannot.

You will often find that stakeholders want things you had not guessed. A department head may care less about the new system's features than about not being blamed if something fails in the first month. A neighbor may not oppose the construction at all but is anxious about noise at night. A lender may be most concerned about being informed early, not about the numbers being perfect. Each of these is easy to address once you know it, and expensive to discover late.

Diverse stakeholders around a meeting table with floor plans and coffee while a project manager listens attentively
The most useful skill in stakeholder work is asking and then listening.

Step four: choose how to engage each group

Now turn the map into actions. For each important stakeholder, write down three things: what you need from them, what they need from you and how often you will talk. Then choose the right style.

For the key players, think partnership. Involve them early, share draft plans and ask for their view before decisions, not after. A fifteen-minute call every week is better than a two-hour presentation every quarter. For the keep-satisfied group, think respect for their time: short written updates, a clear line on what you need from them and when, and no surprises. For the keep-informed group, think openness: regular updates through channels they actually use, a place to ask questions and visible responses to what they say. For the monitor group, a simple check every month is enough.

I describe how to plan and schedule these conversations in the communication plan people actually read, and how to keep a senior sponsor engaged in keeping your executive sponsor engaged. Together with the map, those are the three pieces of a stakeholder strategy.

The hidden stakeholders

Every project has a handful of people who do not appear on the organization chart but hold quiet power. The assistant who controls the executive's calendar. The accountant who decides which invoices get paid this week. The operator on the night shift who knows exactly how the machine really works. The foreman whose crew will either follow the new procedure or not. The person in the municipality who actually reads the permit applications.

You find them with curiosity and humility. Ask experienced people: "Who really decides this?" "Who do you call when you need it fast?" "Who has stopped a project like this before, and why?" Imagine a hospital fit-out where the person who decides whether a critical delivery arrives on time is neither an executive nor a manager, but a dispatcher at the supplier. Treating that person as a valued partner, instead of an anonymous voice on the phone, can be worth more than any escalation.

Supporters, neutrals and resisters

Mapping power and interest tells you how much attention a stakeholder deserves. A second view tells you where they stand. For each key stakeholder, note their current attitude: unaware, resistant, neutral, supportive or actively leading. Then decide what attitude you need from them for the project to succeed. You do not need everyone to be a champion. You need the people with real power to be at least neutral and the people who must use the result to be at least willing.

The gap between current and needed attitude is your work plan. Moving someone from unaware to neutral often takes only information. Moving a resister to neutral usually takes listening, because resistance has a reason. It could be fear of extra work, a past bad experience, or a genuine objection you have not yet understood. If you take the objection seriously and respond to it, the resister sometimes becomes your best critic and later your best advocate. This overlaps strongly with the people side of change, which I explore in change management and the people side of projects.

When stakeholders want different things

Conflicts between stakeholders are normal. The client wants it sooner, finance wants it cheaper and operations wants it simpler. A project manager's job is not to make everyone happy but to make the trade-offs visible and get decisions made by the right person.

Three habits help. First, agree early on priorities: what matters most among cost, time, scope and quality, and who decides when they conflict. Often that is the sponsor. Second, put the trade-off in front of the decision-maker in plain terms: "To finish a month earlier we need $80,000 more or we cut the second phase. Which do you choose?" Third, write the decision down and share it with the people it affects. This avoids the quiet re-negotiation that happens when people remember agreements differently.

A community meeting in a small hall with residents seated and a project manager pointing at a simple site map on an easel
Showing a simple map to the people it affects is often the best engagement tool there is.

How different kinds of projects change the map

The method is the same, but the map looks different depending on the project.

On public works, authorities and oversight bodies sit in the top-right corner, and the paperwork they require is part of the critical path. The communities along the route have low formal power but can still cause delays through protests or legal action.

On a startup launch, the early customers, a couple of advisors and the first key hires hold disproportionate power. The map is small but each person on it matters.

On a clinic or hospitality opening, the inspectors, the staff who will work there and the first guests or patients decide the early reputation, as I describe in how a clinic opens on time.

On an internal process change, the loudest stakeholders may be middle managers whose teams are affected and who have the power to make the new process work or fail.

On a partnership or investment project, the counterparty's advisors, lawyers and technical reviewers often hold more practical power than the person you negotiate with. That is part of why I treat partnerships as projects in my business partnerships service.

Five mistakes that cost projects

Stakeholder work is simple, and that is exactly why teams skip it. Here are five mistakes I see over and over, together with the fix for each.

Treating the sponsor as the only stakeholder. The sponsor matters enormously, but a sponsor cannot make an inspector hurry or a department adopt a tool. Fix: map everyone, then give the sponsor a clear role in unblocking the others.

Engaging only the friendly people. It is natural to spend time with supporters because the conversations are pleasant. Resisters, meanwhile, grow quietly more entrenched. Fix: schedule your hardest conversation first each week.

Communicating at people instead of with them. Announcements are not engagement. If the only channel is a newsletter, you will not hear the objection that could have saved a month. Fix: always build in a way for stakeholders to answer back.

Confusing interest with support. A person who asks many questions is interested, not necessarily supportive. Fix: record attitude separately from interest and revisit it after each conversation.

Forgetting to close the loop. When a stakeholder gives you input, tell them what you did with it, even if the answer is "we could not use it, and here is why." People forgive a no far more easily than silence.

Fixing even two of these puts you ahead of most projects, and the effort is measured in conversations, not in budgets. The conversations are easier when the plan for them is written down, which is exactly what a communication plan is for.

Keep the map alive

A stakeholder map written once and filed away is nearly useless. People change roles, new regulations appear, a sponsor leaves and a quiet neighbor suddenly becomes vocal. Review the map in your regular project meeting, for example once a month, and whenever the project changes significantly: a new phase, a scope change, a key departure. Add a short log: who you spoke to, what you learned and what you promised. Promises are especially important. A promise to a stakeholder is a commitment that should be on the project plan, and it is a surprisingly common source of future trouble when forgotten.

Finally, remember that stakeholder management is not manipulation. It is the respectful practice of understanding the people your project touches and treating them as partners. It takes a few hours at the start. It prevents the sentence "we should have talked to them earlier." If you would like help mapping the people around a project or running the conversations, I do this regularly in the operations and owner's representation service and as part of Project Focus.

Who is the most overlooked stakeholder on your current project? Tell me in the comments.

Frequently asked questions

What is a stakeholder in project management?

A stakeholder is any person or group who can affect a project or who is affected by it. That includes sponsors, customers, the team and suppliers, but also regulators, neighbors, partners and the people who will use or inherit the result.

What is a power and interest grid?

It is a simple four-box map that places each stakeholder by how much power they have over the project and how much interest they have in it. The four boxes are manage closely, keep satisfied, keep informed and monitor, and each calls for a different style of engagement.

How often should a stakeholder map be updated?

Review it at least monthly and whenever the project changes significantly, such as a new phase, a scope change or a change of sponsor. Treat it as a living document rather than a one-time exercise.

How do I find hidden stakeholders?

Ask experienced people who really decides things, who gets called when something is urgent and who has stopped similar projects before. Also ask who would be upset to hear about the project from someone else.

Join the conversation

Did this help? A quick reaction tells me what to write next.

Be the first to react.

Comments

Loading comments…

Leave a comment

Comments are reviewed before they appear. Please keep it respectful and leave links out.

Keep reading

More ideas you may like.

Keep exploring

Related projects and services.

Next step

Let's find the project that moves your business.

Tell me where things are stuck. I will tell you which project I would start with.