Stakeholder mapping is the process of listing everyone who can affect your project or be affected by it, then placing each of them on a grid according to how much power they hold and how much interest they have. The output is usually a two by two chart plus a table, and its purpose is narrow and practical: to decide who you manage closely, who you keep satisfied, who you keep informed, and who you can safely leave alone.
That last group is the reason the exercise exists. Nobody has the hours to brief forty people properly. Stakeholder mapping is a rationing decision dressed up as an analysis, and the projects that skip it do not avoid the rationing, they just do it accidentally, usually by briefing whoever shouts loudest.
Key takeaways
- Power is the ability to stop or change the project. Interest is how much the outcome touches the person's own goals. They are independent, and confusing them is the most common mapping error.
- The four-quadrant grid tells you the effort level. It does not tell you what to do. The column that generates actions is current engagement versus desired engagement.
- A map with no named owner per stakeholder is a diagram, not a plan. Every row needs a person who is accountable for that relationship.
- At portfolio level, set power ONCE at the organization level and interest per project. Otherwise the same CFO appears on thirty maps at thirty different ratings.
- Track sponsor load. An executive sponsoring nine projects has roughly a ninth of the attention each business case assumed, and that is a capacity problem, not a personality problem.
Last updated August 2026.
What is stakeholder mapping?
Stakeholder mapping is the practice of identifying every individual or group with a stake in a project, assessing each one on power and interest, and plotting them so the project team can prioritize its attention. It typically produces two artifacts: a visual grid showing relative position, and a table recording each stakeholder's role, expectations, concerns, and the person accountable for managing them.
The technique comes out of Aubrey Mendelow's work on environmental scanning in the early 1980s and reached project management through the power/interest grid that now appears in nearly every PM textbook. The PMI body of knowledge treats it as part of stakeholder identification and analysis, and the exam material leans heavily on the four quadrants. In practice the grid is the easy part. The hard part is being honest about who actually holds power, which is frequently not the person on the org chart.
Stakeholder mapping, analysis, and the register: which is which
These three words get used interchangeably in meetings and it causes real confusion about what deliverable is being asked for. They are different things and it is worth being precise, because a sponsor asking for "the stakeholder analysis" usually wants the assessment, not the list.
| Artifact | What it is | What it answers | Who maintains it |
|---|---|---|---|
| Stakeholder register | The list. Names, roles, contact details, organization, classification. | Who are they? | Project manager, updated continuously |
| Stakeholder analysis | The assessment. Power, interest, attitude, expectations, concerns, influence over others. | How much do they matter and what do they want? | Project manager with the sponsor, refreshed at phase boundaries |
| Stakeholder map | The visual. The grid, the onion diagram, or the influence network. | Who do we prioritize, and how do they relate? | Whoever runs the workshop, redrawn when the analysis changes |
| Engagement plan | The actions. Desired engagement level per stakeholder plus the specific moves to get there. | What are we going to do about it? | Named relationship owner per stakeholder |
Swipe to see more →
In small projects all four collapse into one spreadsheet, and that is fine. The distinction matters when someone challenges a decision, because the register proves you knew about the person and the analysis proves you weighed them. Note also that the engagement plan is the only one of the four that requires anyone to do anything, which is why it is the one most often missing. The mechanics of who receives what and how often belong in the communication plan, which picks up where the map stops.
How to create a stakeholder map in five steps
The exercise takes about ninety minutes for a mid-sized project if you have the right people in the room, and roughly a day of follow-up interviews if the project crosses functions you do not know well.
- Identify broadly, then cut. Start from the org chart, the process the project touches, the systems it changes, and the budget it spends. Any person or group in those four sweeps is a candidate. Include people who lose something: the team whose manual process is being automated is a stakeholder even if nobody invited them.
- Rate power honestly. Power is the capacity to stop the project, redirect its budget, or withhold something it needs. Ask a single question: if this person said no, what would happen? If the answer is "nothing much", they do not have power, regardless of title.
- Rate interest separately. Interest is how much the outcome affects the person's own objectives, targets, or daily work. A regulator may have enormous power and almost no interest. A frontline supervisor may have huge interest and no power at all.
- Plot and check for surprises. Put the ratings on the grid. The useful moment is when someone in the room says "she cannot possibly be low power". That argument is the value of the exercise, not the chart.
- Assign an owner and a desired engagement level for each row. Without these two fields the map is decoration. The owner is the person who will make the phone call. The desired level is what the project needs from that person for it to succeed.
The power interest grid, and what each quadrant costs when you get it wrong
The four quadrants are standard, and every article about stakeholder mapping lists them. Fewer say what actually happens when a stakeholder is placed in the wrong box, which is the information that makes the exercise worth doing carefully.
| Quadrant | Standard advice | What it means in practice | Cost of misplacing someone here |
|---|---|---|---|
| High power, high interest | Manage closely | Direct contact from the project manager, involvement in decisions, no surprises ever | The project stalls at a gate because the person who could approve it was not consulted and now has questions |
| High power, low interest | Keep satisfied | Brief, infrequent, high-signal updates. Do not consume their attention with detail | They become interested at the worst possible moment, usually when something goes wrong, and arrive with no context |
| Low power, high interest | Keep informed | Regular information, a channel to raise concerns, genuine consultation on things that touch them | Adoption failure. These are usually the people who have to actually use what you built |
| Low power, low interest | Monitor | Minimal effort, periodic re-check | Usually cheap to get wrong, which is why this quadrant is the right place to be generous with your assumptions |
Swipe to see more →
Two practical notes. First, the low power high interest quadrant is where most project failures are seeded, because power is measured in the ability to stop the project and these people cannot stop it, they can only refuse to use it afterwards. That refusal shows up six months later as a benefits shortfall rather than a project problem, which is why it rarely gets traced back. If your project's value depends on people changing how they work, the benefits realization case rests on this quadrant.
Second, a stakeholder's position is not fixed. People move quadrants when the project moves into their territory. A finance director with low interest during design becomes high interest the week the cutover affects month-end close.
Stakeholder analysis matrix template, field by field
Here is the template as a table of fields rather than a downloadable file, because the fields are the whole point and any spreadsheet tool renders them. The third column is the one worth reading: these are the specific ways each field gets filled in uselessly.
| Field | What goes in it | How it gets filled in uselessly |
|---|---|---|
| Name and role | The individual, plus their job title and function | A department name. "Finance" cannot be called, cannot approve anything, and cannot be held accountable |
| Category | Internal, external, supplier, regulator, customer, affected user | Left blank, so nobody notices the map contains only internal people |
| Power (1 to 5) | Ability to stop, redirect, or starve the project | Copied from seniority. The most senior person is not always the one who can block you |
| Interest (1 to 5) | How much the outcome affects their own targets | Rated by how much they talk in meetings, which measures volume, not stake |
| Current attitude | Resistant, neutral, supportive, or unknown | Everyone marked supportive because nobody wants to write down that the head of ops hates it |
| Desired engagement | What the project needs from them: supportive, actively leading, or simply not blocking | Left as "supportive" for all rows, which means the map generates no differentiated actions |
| What they want | Their actual objective, in their words, from a conversation | Guessed. This field is only worth having if someone asked |
| Main concern | The specific thing that would make them oppose it | "Cost" or "timeline", which is true of everyone and therefore tells you nothing |
| Relationship owner | The named person who manages this relationship | The project manager for all forty rows, which is not a plan, it is a bottleneck |
| Next action and date | One concrete move with a date | Omitted entirely, which is how the map becomes a photograph of a whiteboard |
Swipe to see more →
Ten fields is the ceiling for something people will maintain. If your template has twenty columns, the honest prediction is that it gets completed once during initiation and abandoned. The same rule applies to the RAID log and every other living artifact a PMO asks project managers to keep current.
Stakeholder analysis example: a finance system replacement
Abstract templates are easy to agree with and hard to use, so here is a filled version. The project is a nine-month replacement of a general ledger and month-end close process at a mid-sized US company, roughly 900 employees, with a phased cutover.
| Stakeholder | Power | Interest | Attitude now | Needed | Main concern | Owner |
|---|---|---|---|---|---|---|
| CFO (sponsor) | 5 | 5 | Supportive | Actively leading | That the close does not slip in the first quarter after cutover | Program director |
| Controller | 4 | 5 | Resistant | Supportive | Her team absorbs parallel running on top of a normal close | Program director |
| IT infrastructure lead | 4 | 2 | Neutral | Not blocking | An unplanned environment request landing in his change window | Technical lead |
| AP and AR supervisors | 1 | 5 | Resistant | Supportive | Losing workarounds they built over years, with no replacement | Change lead |
| External auditor | 5 | 2 | Neutral | Not blocking | Audit trail continuity across the cutover | Controller |
| Head of FP&A | 3 | 4 | Supportive | Supportive | Reporting hierarchy changes breaking her models | Business analyst |
| Divisional GMs (x4) | 3 | 1 | Unknown | Not blocking | Anything that touches their reported numbers mid-year | Program director |
| Payroll provider | 2 | 3 | Neutral | Not blocking | Interface changes with insufficient notice | Technical lead |
Swipe to see more →
Three things in that table are worth pointing at. The controller is the highest-risk row on the project and she is not the sponsor: she has enough power to make the timeline impossible and she is currently resistant for an entirely legitimate reason. The AP and AR supervisors have power rating 1 and are the single biggest threat to the benefits case, which is exactly the low power high interest trap. And the divisional GMs are marked "unknown" attitude, which is honest and more useful than a guessed "neutral", because it converts into an action: go and ask them.
Current versus desired engagement: the gap that generates actions
The power interest grid tells you how much effort to spend. It does not tell you what to do on Monday. The field that does that is the comparison between where a stakeholder is now and where the project needs them to be. PMI's version of this is the stakeholder engagement assessment matrix, which marks each person's current level with a C and the desired level with a D across five bands.
| Level | What it looks like | Typical gap-closing move |
|---|---|---|
| Unaware | Does not know the project exists, or does not know it affects them | A direct briefing, not a cc on a status email |
| Resistant | Aware and opposed, actively or passively | Find the actual objection. It is nearly always a specific cost to them, not a philosophical position |
| Neutral | Aware, neither supporting nor blocking | Give them a reason to care, or accept neutral and stop spending on them |
| Supportive | Aware and in favor, will not spend their own capital on it | Ask for something specific: a named resource, a meeting slot, a public statement |
| Leading | Actively driving it, spends their own credibility | Protect them. Make sure they are never surprised in public |
Swipe to see more →
The discipline is to write the desired level honestly. Most projects do not need everyone "leading", and marking all rows that way produces a plan nobody can execute. For most of the map the correct desired state is "not blocking", which is cheap to achieve and easy to verify. Reserve "leading" for the two or three people whose visible sponsorship the project genuinely depends on.
Measuring the current level is where teams get lazy and simply guess. On a small project a guess is fine. When a change touches several departments and hundreds of people, guessing the mood of the organization is how projects get blindsided, and a short structured organizational readiness assessment gives you a baseline you can re-measure at cutover rather than an opinion formed in a room of six people.
Stakeholder mapping across a portfolio, not one project
Everything above is standard project practice, and it works. It also breaks down completely the moment you run forty projects at once, which is the situation a PMO is actually in and which almost nothing written about stakeholder mapping addresses.
The specific failure is this. Each project maps its own stakeholders independently. The CFO appears on thirty of those maps, rated power 5 on some and power 3 on others, with thirty different "desired engagement" levels and thirty different relationship owners, all of whom believe they have a claim on her calendar. Nobody has ever added it up. The result is an organization that has, on paper, committed a single executive to leading nine transformations while also keeping her satisfied on twelve others.
The fix has two parts, and neither is complicated.
Split the two ratings by where they belong. Power is a property of the person and the organization, not of the project. Set it once, centrally, in a portfolio-level stakeholder register the PMO owns, and let projects inherit it. Interest is genuinely project-specific and stays with the project. This kills the argument about whether the CFO is a 4 or a 5 on any given map and it means a change in the org structure updates every project at once. It is the same inversion the communication plan benefits from: one standard set at portfolio level, exceptions documented per project.
Then add up the demand. Once power lives centrally you can run the query nobody currently can: for each senior stakeholder, how many active projects list them as sponsor, as a "manage closely" row, or as a required approver? That number is the thing to manage, and it belongs on the agenda of the portfolio review meeting alongside the funding decisions.
Sponsor load: executive attention as a capacity constraint
Portfolio teams are rigorous about people capacity for delivery roles. Nobody assigns a developer to nine projects at 100 percent and expects it to work; that is what capacity planning exists to prevent. The same organizations routinely assign one executive as active sponsor of nine projects and treat any resulting problem as a scheduling nuisance rather than an overallocation.
It is worth counting. Sponsor load is simply the number of active projects for which a given executive is the accountable sponsor, and it behaves like any other capacity number.
| Sponsor load | What you typically see | Portfolio action |
|---|---|---|
| 1 to 2 projects | Sponsor knows the detail, decisions come back within days | None. This is what the business case assumed |
| 3 to 4 | Still workable. Decisions take a week, sponsor relies on the status report rather than direct knowledge | Watch the decision lag; make sure the reporting is genuinely decision-shaped |
| 5 to 7 | Decisions queue behind each other. The sponsor starts delegating to a deputy informally, without telling anyone | Formalize the delegation. Write the deputy into the governance as the decision maker for named categories |
| 8 or more | Sponsorship is nominal. Projects proceed without real cover and discover it at the first escalation | Reassign sponsorship or stop projects. Adding a project to this sponsor is a decision to under-resource all of them |
Swipe to see more →
The numbers are indicative rather than a standard, and the right thresholds depend on how much decision authority sits below the sponsor. What matters is that the count exists and gets looked at. In most portfolios it has simply never been calculated, and calculating it takes an afternoon. The measure to pair it with is how long a decision sits waiting: if requests to one sponsor routinely age past two weeks, the load is too high regardless of what the table above says. That connects directly to what the project sponsor role is supposed to provide and what governance assumes is available.
When to redraw the map
A stakeholder map drawn at initiation and never revisited is worse than none, because it carries the authority of a document while describing an organization that no longer exists. Rather than a calendar cycle, use triggers.
| Trigger | Why it changes the map | What to redo |
|---|---|---|
| Any change in sponsor, or a reorganization above the project | Power ratings are now wrong across the board | Full re-rate of power; interest usually holds |
| Phase boundary or stage gate | The project has moved into someone else's territory | Re-rate interest; new stakeholders will have appeared |
| Scope change that touches a new function | A group you never mapped is now affected | Add rows, assign owners; log opposition risk if attitude is unknown |
| An escalation you did not see coming | Direct evidence that the map was wrong about someone | Re-rate that person and everyone who influences them |
| Approaching go-live | The affected-user population becomes the group that decides whether benefits happen | Deepen the low power high interest quadrant, which is usually the thinnest part of the map |
Swipe to see more →
The scope-change trigger deserves emphasis, because unmapped stakeholders arriving mid-project is one of the ordinary mechanics of scope creep. Someone who was never consulted turns up with a requirement that is genuinely reasonable, and the project has no way to refuse it because it never established who was in scope for consultation.
Where stakeholder mapping goes wrong
It is a useful technique with a high failure rate, and the failures are consistent enough to be worth listing plainly.
It becomes a workshop artifact. The sticky notes get photographed, the photograph goes in a folder, and no row ever produces an action. The test is simple: can you point at a decision that changed because of the map? If not, you did an icebreaker.
Everyone is marked supportive. Writing down that a senior person opposes the project feels politically risky, so the attitude column becomes uniformly positive and the analysis loses its only diagnostic value. If your map has no resistant rows, it is not finished. Real projects always have someone who loses something.
Power is copied from the org chart. The person who can genuinely stop a project is often a technical gatekeeper, a compliance officer, or a long-serving operations manager whose team will not cooperate. Seniority correlates with power but does not equal it.
The map is confidential, so it cannot be used. Written honestly, a stakeholder analysis contains judgments about named colleagues that you would not want circulated. That is a real constraint. The workable compromise is a shared version with names, roles, ratings and owners, and a private working note where the sponsor and project manager record the candid assessment. Pretending the sensitive judgments do not exist just pushes them into corridor conversations where they cannot be challenged.
It stops at identification. By far the most common failure. The list gets built, the grid gets drawn, and nobody assigns the next action with a date. Everything upstream of that column is preparation.
Frequently asked questions
What are the 4 types of stakeholders?
In project management the four types usually refer to the power interest quadrants: high power high interest (manage closely), high power low interest (keep satisfied), low power high interest (keep informed), and low power low interest (monitor). A different four-way split is also common: internal, external, primary (directly affected) and secondary (indirectly affected). Both are in use, so clarify which one is meant.
What is the difference between stakeholder mapping and stakeholder analysis?
Stakeholder analysis is the assessment: rating each stakeholder's power, interest, attitude and expectations. Stakeholder mapping is the visualization of that assessment, most often as a power interest grid. In everyday use the terms are treated as one activity, because you cannot draw a meaningful map without doing the analysis first, and the analysis is hard to interpret without the picture.
What are the 4 quadrants of the stakeholder matrix?
The four quadrants are manage closely (high power, high interest), keep satisfied (high power, low interest), keep informed (low power, high interest), and monitor (low power, low interest). The quadrant sets the effort level for each stakeholder. It does not set the specific action, which comes from comparing their current engagement level against what the project needs.
Who is responsible for stakeholder mapping?
The project manager owns the map and keeps it current, working with the sponsor, who usually has better visibility of political dynamics at senior levels. Individual rows should have their own relationship owner rather than defaulting everything to the project manager. In a portfolio setting the PMO owns the central register of senior stakeholders and their power ratings.
How do you identify project stakeholders?
Sweep four sources: the organization chart for people with authority over the project, the business process the project changes for the people who run it, the systems and data it touches for their owners, and the budget for whoever funds it. Then ask each person you identify who else you should be talking to. That last question consistently surfaces the stakeholders the first three sweeps miss.
What is a stakeholder engagement assessment matrix?
It is a table that records each stakeholder's current engagement level and the level the project needs, across five bands: unaware, resistant, neutral, supportive and leading. Current is marked C and desired is marked D. The gap between the two is what generates the engagement actions, which is why this matrix is more operationally useful than the power interest grid on its own.
What is the difference between a stakeholder map and a stakeholder register?
The register is the list: names, roles, organizations and contact details for everyone with a stake in the project. The map is the analysis of that list, positioning people by power and interest. The register answers who they are; the map answers who matters most and how much attention each one gets.
How often should a stakeholder map be updated?
Update it on triggers rather than on a schedule: a sponsor change or reorganization, a stage gate, a scope change that reaches a new function, an escalation you did not anticipate, and the run-up to go-live. A light review at each phase boundary is enough for most projects. Calendar-driven reviews tend to become a formality nobody reads.
What is stakeholder mapping in PMP?
In the PMP framework, stakeholder mapping sits within stakeholder identification and analysis. The exam material covers the power interest grid, the related power influence and impact influence grids, the salience model (power, legitimacy, urgency), and the stakeholder engagement assessment matrix. The stakeholder register is the named output of the identify stakeholders process.
Can you do stakeholder mapping in Excel?
Yes, and for most projects a spreadsheet is the right tool. Keep one row per stakeholder with columns for power, interest, attitude, desired engagement, relationship owner and next action, then use a scatter chart with power and interest as the axes to produce the grid automatically. Dedicated mapping software matters only when you need to model influence relationships between stakeholders rather than just their positions.
What should a stakeholder analysis include?
At minimum: the person's name and role, their category, a power rating, an interest rating, their current attitude, the engagement level the project needs from them, what they actually want, their main concern, a named relationship owner, and one next action with a date. Ten fields is about the practical limit for something a project team will keep current.
Where this fits with the rest of the governance set
Stakeholder mapping is the first of several artifacts that overlap enough to confuse people, so it is worth stating the boundaries. This page covers who the stakeholders are and how much power and interest each one has. Accountability for the work itself belongs to the RACI matrix. The routine of who receives what information and how often belongs to the communication plan. The forum where senior stakeholders actually make decisions is the steering committee, and the first version of the map is normally produced when the project charter is written and confirmed at the kickoff meeting.
One boundary is worth calling out explicitly, because it is the one teams get wrong most often. A stakeholder who is expected to actively oppose the project is not just a row on the map. Once opposition is likely enough and damaging enough to warrant a mitigation, it becomes an entry in the risk register with an owner and a response, and the map is the evidence behind it rather than the place it gets managed.