Stakeholder Analysis for Business Analysts
A Practical Guide
Most projects that go badly do not go badly because someone built the wrong screen. They go badly because a decision was made without the person who should have been in the room, or because someone who could stop the work was not taken seriously until they did.
Stakeholder analysis is the work that prevents that. It is not a form you fill in at the start of a project. It is a set of practices for finding out who is affected by a change, understanding what each of them needs and can do, and staying in contact with that picture as it shifts.
This guide walks through the whole process: why it matters, how to find stakeholders, how to analyze them once you have them, how to build the relationships that make the analysis accurate, and what to do with it all once it exists. Each section points to a more detailed article if you want to go further.
Why stakeholder work decides outcomes
A stakeholder is anyone affected by a change, able to affect it, or holding a legitimate interest in how it turns out. That definition is broader than most people expect, and the breadth is the point.
It is tempting to treat stakeholders as a list of people to keep informed. That framing makes stakeholder work feel like an administrative chore, and it leads to the version of the practice that nobody benefits from: a spreadsheet of names, a communication plan nobody reads, and a monthly email.
The useful framing is different. Stakeholders are where your requirements come from, and they are also where your constraints come from. A requirement you never heard is not a requirement you can deliver. A constraint you discover in month six costs more than the same constraint discovered in week two. Both of those are stakeholder problems before they are anything else.
There is a second reason, harder to see early in a career. Stakeholders disagree with each other. Not through obstruction, but because they occupy different positions and see different things. A finance director and a frontline supervisor can both describe the same process accurately and reach opposite conclusions about what should change. Surfacing that disagreement early is one of the most valuable things a business analyst does, and you cannot surface it if you have not identified both people.
If you want the fuller argument, including what it costs when this goes wrong, read why stakeholders matter to the outcome of a change.
Finding the stakeholders
The first instinct is to write down the names you already know. That gets you the people you have met, which is not the same as the people who matter.
Systematic identification means working from a structure rather than from memory. There are three approaches worth knowing, and they do different jobs.
The onion model starts at the solution and works outward in layers: the people who operate it, the wider business system around them, and the environment beyond that, including regulators, suppliers, and customers. It is the best starting point because it prompts you to look in places you would not have thought of. Most missed stakeholders live in the outer layers. See identifying stakeholders with the onion model.
A nomination procedure takes a different route. Instead of you working out who should be involved, you ask the organization to name people formally, with a defined role attached. This matters in larger organizations, where you do not know the structure well enough to find the right person and where an informally involved stakeholder has no mandate to decide anything. See the stakeholder nomination procedure.
A checklist is your backstop. You run it after you think you are finished, and it catches the categories you skipped. Nobody finds every stakeholder on the first pass, so the value is in the second pass. See the stakeholder identification checklist.
In practice you use more than one. Start with the onion model to generate breadth, use nomination where you need formal authority behind a role, and run the checklist before you consider the list stable.
One habit worth forming now: record why each person is on the list, not just that they are. Six weeks later, when someone asks why the compliance manager is in a workshop, you want a better answer than a vague recollection.
Analyzing what you found
A list of names does not tell you how to spend your time. You have limited hours, some stakeholders need close involvement and others need occasional information, and treating everyone identically means both over-consulting people who do not want it and under-consulting people who do.
Analysis is how you make that judgment defensible rather than instinctive.
The usual starting point is Mendelow's matrix, which places stakeholders against power and interest. Someone with high power and high interest needs close management. High power and low interest needs to be kept satisfied, because they can intervene even though they are not paying attention. Low power and high interest needs to be kept informed. It is a simple model and it is the right first tool, because it produces a usable answer quickly and it gives you a shared language for a conversation with your project manager. See stakeholder analysis with Mendelow's matrix.
Mendelow has two well-known limits, and each has a way that addresses it.
The first is that power and interest tell you nothing about whether someone supports the change. Two stakeholders can sit in the same quadrant while one is your strongest advocate and the other intends to block you. Adding attitude as a third dimension separates them, and it changes what you do next: an influential supporter is someone to deploy, an influential opponent is someone to understand before you do anything else. See adding attitude to your stakeholder analysis.
The second limit is time. Mendelow gives you a fairly static picture, and real projects need to know who matters this month. Stakeholder salience works through power, legitimacy, and urgency, and the urgency dimension is what makes it useful when you are deciding where attention goes right now rather than in general. See an introduction to stakeholder salience.
So: Mendelow to get a working picture, attitude when you need to know who is with you, salience when you have more competing demands than hours. You do not need all three on every project, and using all three on a small piece of work is a way of looking busy rather than being useful.
A word of caution about all of these. The output of a stakeholder analysis is a set of judgments about real colleagues, some of them unflattering. Be deliberate about where that document lives and who can see it.
Building the relationships that help the analysis
Here is the part that surprises people who come to stakeholder work through a certification syllabus. The frameworks above depend entirely on the quality of your information, and the quality of your information depends on whether people tell you the truth.
Stakeholders do not always say what they think. They tell you the version that is safe to say in a meeting, or the version that matches what their manager said last week, or nothing at all, because they have watched previous analysts arrive, ask questions, and disappear. None of that shows up in a power-interest grid. It shows up as a requirement that turns out to be wrong at the point where wrong is expensive.
Rapport is what changes that, and it is worth being precise about what rapport actually is. It is not being liked, and it is not small talk before the real conversation starts. It is a working relationship in which someone is willing to tell you something inconvenient. That is a skill with observable mechanics, not a personality trait you either have or do not.
This is the least documented part of stakeholder work and the part that separates analysts who produce accurate requirements from analysts who produce plausible ones. Start with rapport as a skill, which links on to the mechanics in more detail.
Turning analysis into engagement
An analysis that sits in a document changes nothing. The last step is deciding what you actually do with each stakeholder, and then keeping the picture current.
Engagement means matching the contact to the analysis. Close management usually means involvement in decisions, not just attendance at a demo. Keeping someone satisfied often means a short direct conversation rather than inclusion in a distribution list they will never read. Being kept informed can be satisfied by a channel they already use. The question is not how often to communicate but what each person needs in order to contribute or to not obstruct.
Then there is the part most projects skip entirely. Stakeholder analysis has a shelf life. People change roles. A reorganization moves authority somewhere else. A stakeholder who was neutral becomes an opponent because of something that happened in a different project. An initiative that had low urgency becomes board-level attention after an incident.
If your analysis was done once, in week one, and never revisited, it is describing an organization that no longer exists. Revisit it at points where something has genuinely changed: a phase boundary, a change of sponsor, a significant shift in scope. That is a lighter habit than it sounds, and it is the difference between stakeholder analysis as a practice and stakeholder analysis as a deliverable.
If your organization wants to build this capability across a team rather than in individuals, our stakeholder engagement course covers the full process with practical application.
Where to start
If you are new to this and want a sequence rather than a set of options, do it in this order.
Identify broadly first, using the onion model, and resist the urge to filter as you go. Filtering during identification is how stakeholders get missed. Then run the checklist and see what you forgot, because you will have forgotten something. Then analyze with Mendelow to get a working picture of where your time should go, and add a second framework only if you hit a question Mendelow cannot answer.
Then, and this is the step people skip, go and have real conversations with the people at the top of your list before you write anything down as fact. The analysis tells you who to talk to. It does not tell you what is true.
And keep the whole thing alive. The version of stakeholder analysis that helps you is the one you revisit, not the one you complete.