By Ritvars Mētra, Founder of ReadinessCompassStakeholder analysis is one of those change-management activities everyone claims to do. A spreadsheet appears. Names are listed. Influence and interest are rated, often with suspicious confidence. Someone adds “supportive,” “neutral,” or “resistant.” The file is saved in the programme folder, occasionally shown in a governance meeting, and then—too often—it quietly becomes administrative wallpaper.
Which is odd, because stakeholder analysis should be one of the strongest predictors of adoption. Not adoption in the abstract. Real adoption. The kind where people stop using the old workaround, trust the new process enough to rely on it, change how they make decisions, and keep doing it after the project team has moved on.
Why stakeholder analysis predicts adoption better than communication
Stakeholder analysis is where we first start to see whether adoption is likely. A poor stakeholder analysis asks, “Who needs to be informed?” A better one asks, “Whose behaviour, judgment, influence, permission, or silence will determine whether this change actually sticks?” That second question is much more interesting. Also more dangerous, because it exposes what polished plans often hide: adoption is not evenly distributed. Some stakeholder groups matter because they are heavily impacted. Others matter because they control resources. Some matter because everyone watches them. Some matter because they know how the work really gets done.
This is why stakeholder analysis connects so directly to adoption. It identifies the human system through which the change must travel. In transformation programmes, we often talk about adoption as if it were the final step: build the solution, communicate it, train users, measure usage. Done. But adoption starts much earlier. It starts when stakeholders first interpret the change.
A stakeholder analysis that only captures influence and interest misses the psychological layer. Influence matters, yes. Interest matters too. But adoption depends on more than where someone sits in a power-interest grid. It depends on perceived impact, trust in sponsors, readiness, capability, workload, local history, incentives, social norms, and the question people rarely ask out loud: “What happens to me if this succeeds?”
Take a CRM transformation. Senior leaders may see better pipeline visibility. Sales managers may see improved coaching opportunities. Sales representatives may see surveillance, extra admin, and less room for relationship-based selling. Marketing may want cleaner segmentation. Finance may want forecast discipline. Same CRM, different worlds. Without stakeholder analysis, the programme hears only “CRM rollout.” With proper stakeholder analysis, it sees multiple adoption journeys running in parallel.
Stakeholder analysis as segmentation for change
This is where adoption becomes practical. Stakeholder analysis tells us where generic communication will fail. One group may need a strategic narrative: why the change matters. Another group needs role-based training. Another needs manager talking points because employees trust their line manager more than a central project email. Another needs early involvement because they are informal opinion leaders.
There’s a mild heresy here: not every stakeholder needs the same level of involvement. Participation sounds virtuous, and often it is, but universal involvement can become slow, performative, and exhausting. The goal is not to invite everyone into everything. The goal is to understand whose involvement improves adoption, whose alignment reduces risk, whose feedback improves design, and whose visible support creates permission for others to move.
Stakeholder analysis, done well, is segmentation for change. Organisations already understand segmentation when dealing with customers. They map needs, behaviours, pain points, channels, journeys, decision triggers. Then, strangely, they treat employees as one mass audience called “the business.” This always strikes me as a little absurd.
The different roles stakeholders play in adoption
In adoption terms, different stakeholders play different roles. Sponsors create legitimacy. They signal that the change is not optional theatre. But sponsorship only helps when it is active and consistent. A sponsor who appears at kick-off and vanishes until go-live is mostly decorative.
Middle managers translate. They are adoption multipliers, or adoption blockers, depending on whether they understand the change, believe in it, and have the capacity to lead their teams through it. Many transformations underinvest here. They brief managers late, overload them with cascade packs, and then act surprised when messages arrive distorted or half-hearted.
Frontline users validate reality. They know which process steps are ceremonial, which system fields are fake, which exceptions happen daily, and which “simple” changes will break something important. If they are not analysed properly as stakeholders, the programme may design adoption support around an imaginary version of work.
Informal influencers spread norms. They may have no official title. Sometimes they are senior experts, respected coordinators, super users, or simply the person everyone asks when the system behaves strangely. Their adoption matters because other people copy their interpretation. A good stakeholder analysis maps these roles. A weak one maps job titles.
McKinsey’s survey of 1,657 executives found that only 39 per cent said their organisation had built broad ownership of the change effort, falling to 11 per cent where transformations failed — and that frontline employees consistently rated the communication they received as less effective than their leaders believed it to be. A register that stops at names and reporting lines cannot detect either gap.
Influence rated
Adoption risk assessed
Engagement planned
Behaviour shifted
Example: stakeholder analysis becomes useful when influence ratings are connected to engagement plans that lead to observable adoption behaviours.
How to read resistance as adoption data
The adoption connection becomes even clearer when we look at resistance. Resistance is often treated as something stakeholder analysis should predict so it can be “managed.” That’s partly true, but the word managed can hide a lot of bad behaviour. Resistance is not just friction. It is information.
If a stakeholder group resists because they don’t understand the change, that is an awareness problem. If they understand it but disagree with the rationale, that is a conviction problem. If they agree but lack skills, that is a capability problem. If they have skills but no time, that is a capacity problem. If they are capable but their manager still rewards the old behaviour, that is an incentive problem. All of these look like “resistance” from a distance. They require completely different interventions.
Stakeholder analysis helps adoption because it forces diagnosis before treatment. Without it, organisations prescribe training for everything. Training for lack of awareness. Training for political conflict. Training for bad process design. Training for fear. Training for workload. Training becomes the aspirin of transformation: always available, often insufficient. Adoption needs sharper medicine.
Keeping the stakeholder map alive
This is also why stakeholder analysis should not be static. Stakeholders move. Their influence changes. Their commitment changes. Their concerns mature as they learn more. A group that looked neutral during design may become highly resistant during testing because the real workload finally becomes visible. A sceptical manager may become an advocate. A sponsor may lose credibility. The stakeholder map from month one is not wrong exactly. It is just old. In transformation work, old can be dangerous.
The practical link between stakeholder analysis and adoption is strongest when the analysis feeds decisions. Who needs early involvement? Who needs targeted communication? Where do we need manager enablement? Which groups need deeper impact assessment? Where is adoption risk concentrated? What should we measure?
If the stakeholder analysis does not change the adoption plan, it has probably become a ritual. There is a simple test: after reviewing the stakeholder analysis, ask what the team will do differently because of it. If the answer is vague—”we will communicate more”—the analysis is not yet useful. If the answer is specific—”we need to involve regional sales operations before process sign-off” or “line managers need a separate briefing because they are the trusted adoption channel”—then the work is beginning to matter.
Adoption is not only an individual decision. It is a social process shaped by trust, influence, relevance, capability, and local meaning. Stakeholder analysis gives us a way to understand that social process before it hardens into cynicism or quiet non-compliance. A stakeholder register can tell you who exists. Stakeholder analysis should tell you how adoption will happen—or why it probably won’t.
For a practical step-by-step method, see how to conduct stakeholder analysis. Browse the broader stakeholder analysis resources for related guidance on resistance, sponsorship, communication and diagnostic tools.