Stakeholder Analysis: The Power-Interest Grid Explained

Stakeholder analysis is the step most project managers skip when time is tight. It's also the step that explains why a technically sound project still gets cancelled, delayed, or quietly defunded. Before you build a plan, you need to know who has the power to stop it and whether they want to.

What is stakeholder analysis?

Stakeholder analysis is a structured process for identifying the people and groups who affect or are affected by your project, then assessing their level of power and interest so you can engage each one appropriately. It's not a one-time exercise. It's an ongoing map you update as the project moves through its life cycle.

The point isn't to please everyone. It's to spend your limited communication and relationship-building effort where it actually matters: on stakeholders with the power to accelerate or derail what you're building.

Key Facts

• Projects with effective stakeholder engagement are 2.5x more likely to meet their original goals and business intent (PMI Pulse of the Profession, 2023).
• Poor stakeholder engagement is cited as a top factor in project failure by 37% of organizations surveyed in PMI's 2024 global report.
• Organizations that invest in stakeholder management practices complete 77% of their projects on time, versus 56% for those that don't (PMI, 2023).

The power-interest grid (Mendelow's matrix)

The power-interest grid (also called Mendelow's matrix, after Aubrey Mendelow who introduced it in 1991) plots stakeholders on two axes: how much power they hold over the project outcome, and how much interest they have in that outcome. The result is a 2x2 grid with four quadrants, each calling for a different engagement strategy.

Think of the axes this way: power is the ability to influence decisions, release resources, or block progress. Interest is how much the stakeholder actually cares about what your project does or delivers.

The grid is useful because it forces a concrete judgment. You can't put everyone in "Manage Closely." When you place a stakeholder in a quadrant, you're committing to a specific communication rhythm and level of involvement. That clarity prevents both over-communication (burning out a CFO with weekly status calls) and under-communication (blindsiding a VP whose sign-off you need at go-live).

The most dangerous quadrant

"Keep Satisfied" is where projects die quietly. A senior stakeholder with high power and low interest sounds harmless, until the project impacts something they do care about. An IT security director who wasn't engaged early can halt a software rollout the week before launch because the deployment process wasn't reviewed with them. Their interest was low at the start. It spiked at the worst possible moment. Monitoring for these interest shifts is part of what regular stakeholder analysis reviews are for.

Power-interest grid vs other stakeholder models

The power-interest grid isn't the only stakeholder framework. Two other models come up often: the salience model and the RACI matrix.

The RACI matrix answers the question "who does what on this project?" The power-interest grid answers "who do I need to manage and how?" Both tools are useful and complementary. A project sponsor might sit in the "Manage Closely" quadrant of your stakeholder grid AND hold the "Accountable" role in your RACI. Those are two different things. The grid shapes your communication strategy. The RACI shapes task ownership.

The salience model adds a third dimension (legitimacy) that's valuable when multiple high-power stakeholders have competing and equally valid interests. For most projects below enterprise scale, the power-interest grid is enough.

Why stakeholder analysis matters

Projects don't fail because of bad code or missed deadlines in isolation. They fail because someone with real influence became a blocker, and nobody saw it coming. Stakeholder analysis is risk management applied to people rather than schedules.

It surfaces hidden blockers early. A 15-minute stakeholder mapping session at project kickoff often reveals a department head, a compliance team, or a board committee that everyone knew existed but nobody thought to formally include. Finding them early is far cheaper than managing an objection two weeks before go-live.

It shapes your communication plan. Once you know where each stakeholder sits on the grid, you can build a communication plan with actual purpose: monthly steering committee reports for "Keep Satisfied" executives, weekly demos for "Keep Informed" end users, and daily syncs with the "Manage Closely" sponsor during critical milestones. Without the grid, communication defaults to "send everyone the same update email," which satisfies no one.

It protects your project scope. Scope creep often starts with a high-power stakeholder who wasn't engaged early enough and compensates by inserting requirements late. When you've identified that stakeholder upfront and built them into your process, you capture their requirements before the plan is locked, not after.

It builds trust with the people who matter. Regular, targeted engagement creates stakeholders who feel heard. They're more likely to support the project in steering committee meetings, approve budget requests, and absorb the inevitable bumps without escalating.

Common mistakes

Treating the analysis as a one-time event. Stakeholders move. A director who had low interest in month one becomes deeply invested when the project starts affecting their team's workflow. If you don't reassess the grid periodically, you'll miss these shifts until they become problems.

Focusing only on supporters. It's tempting to spend all your engagement energy on the people who already like the project. But the stakeholders who can damage it are the ones you need to understand best. Resistant stakeholders often have legitimate concerns. Engaging them early turns adversaries into at least neutral parties.

Plotting stakeholders based on their job title rather than their actual behavior. A CFO with formal authority but who delegates every project decision isn't actually high power in practice. Actual power comes from what people do, not what their org chart says they can do.

Ignoring informal influencers. The grid plots formal power, but informal influence is real. A long-tenured team lead with no management title can shape opinion across an entire department. These people don't always appear in an org chart analysis. Ask "who does the team actually listen to?" when building your list.

Listing stakeholders but never defining engagement actions. A completed grid with 20 names sorted into four quadrants is only half the job. Each quadrant needs a concrete engagement plan: what you send, how often, who sends it, and what feedback loop exists for each group.

Assuming the grid is secret. Some project managers treat stakeholder maps as internal political documents. Sharing the grid (at a high level) with your sponsor and core team improves it. Others in the room will spot missing names and catch misclassified power levels.

How to do a stakeholder analysis

Step 1: Identify your stakeholders

Start with anyone who affects or is affected by the project. Cast the net wide at this stage. Include internal teams, external partners, customers, regulators, sponsors, and end users. Good sources for this list include your project charter, the work breakdown structure, the org chart, and direct questions to your sponsor: "Who else needs to know about this? Who could block it?"

Aim for a list of 15 to 40 names for a mid-size project. Too few and you're probably missing someone. Too many and the list is noise rather than signal.

Step 2: Assess power and interest

For each stakeholder, make two judgments: How much power do they hold over this project? And how much do they care about the outcome?

Keep it simple. A three-point scale (Low, Medium, High) works well. The goal isn't precision. It's relative positioning. Is this person more powerful than that person? Does this team care more about the outcome than that department? You'll place them on the grid by these relative scores.

Talk to your sponsor and core team before finalizing assessments. One person's read on a VP's interest level isn't always accurate. Triangulate.

Step 3: Map stakeholders on the grid

Place each stakeholder in one of the four quadrants based on their power and interest scores. If a stakeholder falls on a border, pick the quadrant that reflects the more consequential risk: it's usually better to over-engage than to under-engage someone with real influence.

Document why each placement was made. When the grid gets reviewed or challenged, you need a rationale, not just a dot on a chart.

Step 4: Define an engagement strategy for each quadrant

Assign a communication approach to each quadrant and then tailor it for individual high-priority stakeholders.

For "Manage Closely" stakeholders: schedule regular one-on-ones, involve them in key decisions, share draft documents before they're final, and create a clear path for them to raise concerns directly. For "Keep Satisfied" stakeholders: send executive summaries at major milestones, flag decisions that require their input, and avoid overwhelming them with detail they didn't ask for.

For "Keep Informed" stakeholders: build a consistent update cadence (newsletters, demo sessions, town halls depending on their scale) and create feedback channels so they can surface issues. For "Monitor" stakeholders: set a periodic review trigger (monthly or quarterly) to check whether their interest has shifted.

Connect your stakeholder engagement plan to your project charter so communication commitments are visible from the start, not retrofitted after someone complains they weren't kept in the loop.

Step 5: Monitor and reassess

Stakeholder maps go stale. Build a review checkpoint into every major project phase: at the end of initiation, after each significant milestone, and before any major announcement or deployment. During the review, ask three questions: Has anyone's power changed? Has anyone's interest shifted? Are there new stakeholders who weren't on the list at kickoff?

Track any significant changes. A stakeholder who moves from "Monitor" to "Manage Closely" mid-project is a warning sign worth documenting. Log them in your RAID log as a risk or assumption update if their shift could affect the project timeline or scope.

Stakeholder analysis example

Here's how stakeholder analysis works for a company-wide CRM software rollout across a 400-person sales and marketing organization.

Project context: Replacing a legacy CRM with a modern platform. The project touches every salesperson's daily workflow, requires IT infrastructure changes, involves a third-party vendor, and needs sign-off from the executive team and legal.

Note the IT Security Team row. They start with low interest but high power. That's a "Keep Satisfied" placement, but with a flagged risk: their interest will spike when deployment security requirements are reviewed. Identifying that early means the PM schedules the security review at month two rather than discovering the blocker at go-live.

Best practices

• Name every stakeholder as an individual, not a department. "Marketing" doesn't have opinions. The Marketing Director does. Individual names create accountability.
• Revisit the grid at every phase gate. A stakeholder map built at kickoff and never touched again is a false comfort.
• Document the reasoning behind each placement. When a stakeholder challenges their quadrant classification, you need a clear rationale, not a defensive explanation.
• Link your stakeholder map to your RAID log. Stakeholders who could shift from low to high interest are risks worth logging. Stakeholders whose support you're counting on are assumptions worth validating.
• Use the grid to prioritize, not to exclude. A "Monitor" stakeholder still deserves periodic attention. The grid tells you where to spend more energy, not who to ignore.
• Share the grid with your project sponsor. They know the organizational politics better than anyone. A 20-minute review of the grid with your sponsor will improve it significantly.
• Align your project scope statement with stakeholder input captured during analysis. Requirements that flow from "Manage Closely" stakeholders should be built into scope before the plan is locked. Surprises from this quadrant are expensive.
• Watch the "Keep Satisfied" quadrant most carefully. High-power, low-interest stakeholders are the most dangerous kind of surprise. Their disengagement is normal until suddenly it isn't.

Frequently asked questions

What's the difference between a stakeholder map and a stakeholder analysis?

A stakeholder map is the visual output (the 2x2 grid with names plotted in quadrants). A stakeholder analysis is the full process: identifying stakeholders, assessing power and interest, mapping them, defining engagement strategies, and monitoring for changes. The map is one artifact produced by the analysis. Using both terms interchangeably is common, but technically the analysis is the broader exercise.

How many stakeholders should be on the grid?

For most mid-size projects, 15 to 40 stakeholders is a reasonable range. Fewer than 10 and you've likely missed someone. More than 60 and the grid becomes unmanageable. Large programs may have multiple grids: one for the overall program and one per workstream or project phase.

Can a stakeholder be in more than one quadrant?

No. Each stakeholder gets one placement at any given point in time. If their power or interest changes, you update their position. The grid is a snapshot. Keeping one stakeholder in a single quadrant at a time prevents the ambiguity of "well, they're sort of in two places."

What's the difference between stakeholder analysis and the RACI matrix?

They answer different questions. Stakeholder analysis asks: who are all the people affected by or affecting this project, and how should we engage them? The RACI matrix asks: for each specific task or deliverable, who is responsible, accountable, consulted, and informed? Stakeholder analysis is broader and more strategic. RACI is task-level and operational. You typically build the stakeholder analysis before the RACI, since knowing who matters helps you decide who belongs in RACI roles.

When should stakeholder analysis start?

Before the project charter is finalized, ideally. The stakeholder map directly informs what gets included in the charter's communication plan and governance structure. At the very latest, complete the initial analysis during the project initiation phase. Trying to do it after planning is locked means you're already behind.

---

The power-interest grid won't tell you what to build. But it will tell you who's going to decide whether what you build succeeds. That's the map worth making before anything else.

Related reading

• RACI Matrix: What is it and examples in everyday use
• Project Charter: The document that starts every project right
• Project Scope Statement
• RAID Log: Track Risks, Assumptions, Issues, and Dependencies
• Project Life Cycle: Phases, Models, and How to Choose
• Work Breakdown Structure
• Risk Register
• MoSCoW Prioritization