Make the map answer who decides
Your AI rollout has a list of obstacles, but the next meeting still ends with “Who can actually fix this?” A stakeholder mapping process should give you an answer for each selected barrier: who acts, who authorizes and where an unresolved decision goes.
We think an influence grid is a useful start, but it falls short when nobody accepts the work. Build an action register alongside it so every barrier has a route to a decision.
The Office for National Statistics’ stakeholder guidance, published in February 2024 and updated in June 2026 for engagement with statistics users, starts by defining who counts as a stakeholder. The tutorial below adapts that guidance and official decision guidance into an editorial workflow; it isn't evidence that mapping improves adoption or productivity.
Sources: Stakeholder mapping – Government Analysis Function
Bound your AI stakeholder mapping
Choose one rollout boundary for your stakeholder mapping process, such as a sales team's use of an approved AI assistant. Gather reported barriers, identify affected employees and obtain your existing approval and delegation rules before assigning responsibilities.
Treat employee responses as reported obstacles to clarify, rather than proof of their causes. They don't establish causal productivity effects.
AI Adoption Score's AI Adoption Barriers identifies reported obstacles across six areas and assigns starting owner categories: IT, leadership, managers or training. Those categories help route the conversation; you still need an individual who accepts the action and a locally authorized decision-maker.
Use these suggested preparation checks before you begin.
Sources: AI Adoption Barriers: how it works · AI Adoption Score, Government Functional Standard - GovS 005: Digital (HTML) - GOV.UK
Follow the stakeholder mapping process
ONS defines influence as the ability to affect outcomes. Keep that separate from authorization: GovS 005, updated on 1 October 2026 for UK government digital and data activity, specifies authority limits, decision roles, accountabilities and escalation routes. Your organization's rules determine who can approve the proposed change.
The UK public-sector Architectural Decision Record Framework, published in November 2025, tells architectural decision-makers to establish scope and the appropriate decision level. The following suggested sequence extends that principle to adoption barriers; it isn't a universal corporate requirement.
We'd assign one person to move each action forward, even when several teams contribute. Shared input shouldn't leave you with an unnamed coordinator.
- Translate the barrier into a proposed action and decision. Ask, “What needs to change, and what approval would allow it?”
- Identify affected employees and influential stakeholders. Ask who experiences the obstacle, controls a dependency or can affect the outcome.
- Name the action owner and authorized decision-maker separately. Confirm that each accepts the assignment and that approval fits existing authority limits.
- Agree an escalation trigger and recipient. Suggested triggers include a missed decision date, insufficient authority or a dependency affecting another team; specify the decision you need.
- Review every assignment with those involved. Record the due date and completion evidence, then confirm no required field remains unassigned.
Sources: Stakeholder mapping – Government Analysis Function, Government Functional Standard - GovS 005: Digital (HTML) - GOV.UK, Architectural Decision Record Framework - GOV.UK
Test assignments against one real decision
For AI stakeholder analysis, ask whether your register can carry an actual request through approval. Imagine a sales team reporting that it lacks learning time: “Provide training” leaves the capacity decision unresolved. The stakeholder mapping examples below form one hypothetical record, with invented names and locally assumed roles.
Use this suggested register structure, then replace every assignment with an accepted local one.
| Field | Example entry |
|---|---|
| Reported barrier | Sales employees report insufficient learning time |
| Affected group | Account executives and their team leads |
| Proposed action | Draft a protected practice-time proposal |
| Action owner | Maya Chen, sales team manager |
| Decision required | Approve a revised workload allocation |
| Authorized decision-maker | Daniel Okafor, sales director, subject to delegation rules |
| Escalation recipient | Commercial operations forum |
| Escalation trigger | Unresolved capacity conflict at the decision deadline |
| Due date | 30 October, illustrative deadline |
| Completion evidence | Recorded approval and published workload allocation |
Resolve authority gaps before closing actions
If two teams dispute ownership, separate their contributions and name one coordinator. If an owner lacks approval authority, keep the action assigned but route the decision to someone authorized. If a dependency crosses teams, record the dependency and the receiving forum rather than leaving “escalate” as an instruction.
The November 2025 Architectural Decision Record Framework identifies effects on integration, shared components or cross-team delivery timelines as architectural escalation criteria. Use those as prompts for agreeing local equivalents, rather than automatic rules for every adoption issue.
In our view, a completed action needs evidence of what changed, not just a green status. Keep accepted assignments and documented decisions separate from later employee reports about whether the obstacle remains.
Finish your stakeholder mapping process by asking each owner and decision-maker to confirm their part. Put the next unresolved decision in front of the person who can make it.
Sources: Architectural Decision Record Framework - GOV.UK
Frequently asked questions
Who should maintain the register?
Choose one coordinator for the rollout as an editorial starting point. A transformation lead or AI program manager could maintain assignments and arrange reviews, while individual owners remain responsible for their actions. Give the coordinator a named sponsor to contact when ownership disputes cannot be resolved within the working group.
How often should we review the map?
Review it when a decision is due or the rollout changes, as a suggested operating practice. Use your existing project meetings where possible. A new team, tool, policy constraint or approval boundary should prompt a check that affected stakeholders, decision-makers and escalation recipients still match the work.
How much employee feedback should we collect?
Collect enough detail to describe the obstacle and the proposed response, rather than designing a large research exercise by default. As editorial guidance, ask affected employees for a concrete task example and invite them to review the proposed action. Avoid requesting personal details that the decision doesn't need.
