How to Conduct Stakeholder Analysis in Change Management

Stakeholder analysis in change management is the structured process of identifying the people and groups connected to a change, understanding how they are affected, assessing how much influence they hold, and deciding how to involve them. It turns broad labels such as “the business” or “users” into an evidence-based view of the human system through which implementation must travel.

The aim is not to complete a stakeholder register for governance. It is to make better decisions about design, sponsorship, communication, resistance, capability and adoption. A useful analysis shows who must decide, who must change behaviour, who can legitimise or block the work, whose operational knowledge is essential, and where engagement needs a clear owner.

This guide explains how to conduct the analysis as a repeatable change-management method. For related articles, research and tools, browse the stakeholder analysis resources.

Why stakeholder analysis matters in change management

Transformation changes more than a system or process. It can alter roles, decision rights, reporting lines, performance expectations, routines, customer interactions and professional identity. The same change therefore creates different realities for different groups.

In a CRM rollout, senior leaders may see better pipeline visibility while sales representatives see extra administration or surveillance. In an ERP implementation, a global process owner may approve a standard design while plant-level planners know where it will fail in daily work. In an AI programme, the technology team may build the solution while frontline employees decide whether its recommendations are trusted and used.

Stakeholder analysis makes those differences visible before they become adoption problems. It also helps teams avoid overestimating formal authority and underestimating local managers, process owners, super users, employee representatives, operational experts and informal influencers.

1. Define the change scope

Begin by defining what is changing, where, for whom and over what timeframe. Include the technical and organisational dimensions: systems, processes, roles, behaviours, decision rights, data, measures, locations and implementation waves.

A stakeholder map for a global ERP rollout will be different from one for a local process improvement or an AI pilot. If the scope is vague, the list of stakeholders will either be too broad to use or too narrow to reveal the real adoption risks. Record important boundaries and assumptions so the analysis can be revised when the scope changes.

2. Identify stakeholder groups

Use the organisation chart as a starting point, not as the answer. Ask who uses the current process, owns the data, approves exceptions, controls budgets, trains employees, serves customers, manages risk, receives reports or carries operational accountability. Include internal and external groups where relevant: executives, sponsors, middle managers, end users, subject-matter experts, enabling functions, partners, suppliers, regulators, customers and employee representatives.

Map groups at a level that supports action. “All employees” is usually too broad, while hundreds of individual names may be impossible to maintain. Separate groups when their impacts, influence, attitudes or engagement needs are meaningfully different. Add named individuals where a specific sponsor, decision-maker or informal influencer matters.

3. Assess impact

Impact describes how strongly the change affects the stakeholder. Consider changes to tasks, workload, skills, systems, processes, measures, authority, relationships, location, status and exposure to operational risk. A group can be highly impacted even when it has little formal power.

Do not treat the score as a fact without explanation. Record why the impact is high or low and what evidence supports that judgement. Workshops, process maps, role descriptions, change-impact records, testing feedback and manager interviews can all improve the assessment. The explanation is often more useful than the number because it points toward practical mitigation.

4. Assess influence

Influence is the stakeholder’s ability to accelerate, shape, legitimise, slow or block the change. Formal authority matters, but so do expertise, credibility, control of resources, access to leaders, network position and the ability to shape local norms.

A sponsor may control decisions and funding. A middle manager may determine whether teams receive time and reinforcement. An experienced coordinator may have little formal authority but be the person colleagues trust when a new process is unclear. Assess both formal and informal influence, and note what the stakeholder can actually influence.

5. Interpret attitude and resistance

Current attitude can be described as supportive, undecided, unaware, sceptical or opposed, but the label is only a signal. The useful question is why. Resistance may reflect unclear benefits, weak design, workload pressure, loss of control, low trust, missing capability, poor timing, conflicting incentives or genuine operational risk.

Avoid treating resistance as a personality problem. Someone may accept the need for change while rejecting the proposed solution, or support the strategy while doubting that leaders will provide enough capacity. Record concerns and observable behaviour separately from assumptions about intent. Then define the attitude or behaviour the programme actually needs from the group.

6. Map and prioritise stakeholders

A power-interest or influence-impact matrix can help prioritise attention. High-influence, highly affected stakeholders normally require close involvement. High-influence groups with lower direct impact may need concise decision-focused engagement. Highly affected groups with less formal influence still need strong listening, design input and practical support.

The matrix is a decision aid, not a substitute for judgement. Add attitude, trust, group size, timing and network relationships where they change the engagement priority. A neat quadrant can hide an informal influencer, a concentrated blocker or a large group facing severe disruption.

7. Plan engagement

Translate the analysis into a specific engagement approach. Senior leaders may need clear decisions, trade-offs and visible sponsorship actions. Middle managers may need role clarity, talking points, time and escalation routes. End users may need demonstrations, practice, support and feedback loops. Employee representatives or regulators may require early transparency and structured consultation.

Define the purpose of each interaction rather than defaulting to “communicate.” The objective might be to obtain a decision, test an assumption, co-design a process, surface concerns, build capability, confirm readiness or reinforce a behaviour. Set a useful channel and cadence, then connect the engagement to the wider communication, training, impact and risk plans.

8. Assign responsibility and next actions

Every priority relationship needs an owner. Record who will engage the stakeholder, what happens next, by when, and what evidence will show that the interaction achieved its purpose. The owner should have enough credibility and access to carry the relationship; assigning every action to the change team usually weakens accountability.

Connect significant concerns to decisions, risks or mitigations. If a stakeholder raises a valid design issue, the response may require redesign rather than another message. If a sponsor is inconsistent, the action may be a specific leadership commitment rather than a general briefing.

9. Review the analysis throughout implementation

Stakeholder positions change as people learn more and experience the real consequences of implementation. A neutral group during design may become opposed during testing when workload becomes visible. A sceptical manager may become an advocate after being involved in a solution. A sponsor may lose influence when priorities or roles shift.

Review the analysis at key decisions, design checkpoints, testing, deployment planning, go-live and adoption reviews. Update impact, influence, attitude, owners and actions. Ask what has changed, which assumptions were wrong, where engagement is producing movement and which signals now require escalation.

Common mistakes to avoid

• Completing the map once: a static register becomes outdated as scope, people and implementation conditions change.
• Focusing only on executives: managers, operational experts, users and informal influencers often determine whether adoption works in practice.
• Using labels without evidence: “resistant” does not explain the concern or identify the right intervention.
• Sending the same communication to everyone: groups need engagement matched to their role, impact, decisions and timing.
• Leaving actions unowned: analysis has little value when it does not change a decision, relationship or implementation plan.

From stakeholder analysis to action

A strong analysis should change what the programme does. It should clarify where leaders need to act, which groups need early involvement, where process or role impacts need mitigation, how communication should differ, and which adoption signals must be monitored.

If you want a structured way to record groups and compare impact, influence, attitude and priority, the AI-assisted Stakeholder Analysis Tool user guide explains the application and its outputs.