What Is Stakeholder Analysis?

Stakeholder analysis is the process of identifying everyone affected by a project or change, understanding what they care about, how much influence they have, and deciding how to communicate with and manage each of them accordingly. It's a foundational step in both business analysis and project management, because a change that ignores the wrong stakeholder — even unintentionally — is one of the most common ways an otherwise well-planned initiative runs into trouble.

Quick facts

• Stakeholder analysis identifies who is affected by a change, how much influence they have, and what they care about.
• The most common visual tool is a power-interest grid — a simple 2x2 chart plotting stakeholders by their level of power and their level of interest.
• Stakeholders aren't limited to obvious people like the project sponsor — they include anyone whose work, role, or interests are affected, even indirectly.
• This feeds directly into a RACI matrix (who does what) and a communication plan (who needs to know what, and when).
• Getting stakeholder analysis wrong — missing someone influential, or underestimating someone's concerns — is one of the most common causes of project resistance or failure.

The power-interest grid, explained

This simple grid helps decide how much time and communication effort to invest in each stakeholder. A common mistake is treating every stakeholder the same way — spending equal effort on a high-power, high-interest sponsor and a low-power, low-interest observer wastes time on one and risks under-serving the other.

How to do a stakeholder analysis, step by step

1. List everyone who could be affected by, or could affect, the change — not just the obvious sponsor and end users, but also teams whose workflow might change indirectly, compliance or legal if relevant, and anyone whose approval is needed.
2. Assess each stakeholder's level of power — their ability to influence the project's direction, approve or block decisions, or provide critical resources.
3. Assess each stakeholder's level of interest — how much the outcome actually matters to them, and how closely they're likely to pay attention.
4. Plot them on the power-interest grid (or a similar tool) to decide how much engagement each one needs.
5. Understand what each key stakeholder actually cares about. Two stakeholders with equal power can have very different priorities — one might care about cost, another about timeline, another about how the change affects their team's daily work.
6. Build a communication plan based on the analysis. High-power, high-interest stakeholders typically need regular, detailed updates and involvement in decisions; low-power, low-interest stakeholders need much less.

A worked example

Picture a company rolling out a new expense-reporting system. A stakeholder analysis might reveal:

• CFO (high power, high interest): cares about cost control and audit compliance — needs to be closely involved in decisions about approval workflows.
• Finance team who'll use the system daily (low power, high interest): cares about how much extra work this creates for them — needs regular updates and a chance to give input on usability, even though they can't block the project.
• IT security (high power, low interest until something concerns them): doesn't care about the project generally, but has the power to block it if there's a data security concern — needs to be consulted early to avoid a late-stage objection that stalls the project.
• Employees submitting occasional expense reports (low power, low interest): just needs simple, clear instructions when the new system launches — doesn't need ongoing involvement.

Without this analysis, a team might over-communicate with employees who don't care much, while under-engaging IT security until a late, costly objection derails the timeline.

Why stakeholder analysis matters beyond just listing names

The real value isn't the list itself — it's using that understanding to prevent avoidable problems. A stakeholder with real power who feels ignored can quietly (or not so quietly) block or slow a project, even if their concerns seem minor to the project team. Identifying this risk early, through structured analysis rather than assumption, lets a team address concerns proactively instead of being blindsided by resistance late in a project.

Common mistakes in stakeholder analysis

• Only listing the obvious, senior stakeholders. Missing a mid-level stakeholder whose team's daily workflow is significantly affected often creates quiet resistance that surfaces later, when it's more costly to address.
• Treating power and interest as fixed, rather than reassessing them. A stakeholder's level of interest or power can shift as a project progresses — revisiting the analysis periodically, not just once at the start, catches these shifts.
• Assuming all high-power stakeholders want the same level of involvement. Some want to be consulted on every decision; others just want confidence that things are on track — understanding each stakeholder's actual preference matters, not just their formal power level.
• Skipping stakeholder analysis for "small" changes. Even smaller initiatives can have an overlooked stakeholder with real influence — the scale of the analysis can shrink for a small project, but skipping it entirely is a risky habit.

FAQ

Who typically performs stakeholder analysis — a business analyst or a project manager? Both roles commonly do this — a business analyst often uses it to understand whose needs shape requirements; a project manager often uses it to plan communication and manage risk. On many projects, both collaborate on a shared stakeholder analysis.

How often should stakeholder analysis be updated? It's not a one-time exercise — revisiting it at key project milestones, or whenever new stakeholders become involved or existing ones' priorities shift, keeps the analysis accurate and useful throughout a project, not just at the start.

What's the difference between stakeholder analysis and a RACI matrix? Stakeholder analysis identifies who's affected and how much they care, and shapes how you communicate with them. A RACI matrix goes a step further, assigning specific task-level responsibility (Responsible, Accountable, Consulted, Informed) — stakeholder analysis often happens first and informs how you build the RACI matrix.

Can stakeholder analysis be too formal for a small project? For very small, low-risk changes, a lightweight, informal version (a quick mental or short written list) is often enough — the key discipline is doing it deliberately, even briefly, rather than skipping the thinking altogether because the project feels small.