Lesson 1 — Stakeholder Analysis and Engagement
Module 3, Unit 4 | Lesson 1 of 3
By the end of this lesson, you will be able to:
- Identify the full stakeholder landscape for an AI initiative, including stakeholders who hold informal influence or are silently affected by the change (K7, K24)
- Map stakeholders by power and interest, and recognise the AI-specific dynamics that distort the standard placement (K13, S3)
- Translate the map into a RACI engagement structure with clear decision rights at each AI governance gate (S4)
- Anticipate the stakeholder behaviours that derail AI projects: shadow users, model sceptics, data owners with effective veto power, and ethics reviewers (B1, B2)
Why stakeholder analysis is different for AI
Most project methodologies treat stakeholder analysis as a planning hygiene step: list the people involved, map them on a 2x2, plan some communications. That works passably for a system upgrade or a process redesign. It tends to fall apart on AI initiatives, because AI projects redistribute three things at once — judgement, risk, and control over data — and each of those redistributions creates stakeholders that the standard project plan does not see.
Judgement gets redistributed because an AI is, almost by definition, encoding decisions that used to be made by people. Those people are stakeholders even when no one has invited them. Risk gets redistributed because AI introduces failure modes — bias, drift, hallucination, opaque rationale — that traditional governance functions did not previously inspect. Risk, compliance, and ethics reviewers therefore become decision gates, not just observers. Control over data gets redistributed because models depend on assets owned by teams who often were not asked. The data steward who was not on the project plan can stop the project on a Tuesday afternoon.
Stakeholder analysis for AI is therefore less about producing a tidy list and more about deliberately surfacing the people the project plan would otherwise miss. It is also less of a one-off step. The stakeholder map for an AI initiative changes between scoping, pilot, and rollout, because the people affected by a model in production are usually different from the people involved in building it.
🔑 Key term: Stakeholder — any individual or group who can affect, or be affected by, the project's activities, outputs, or decisions. The definition (Freeman, 1984) deliberately includes informal influence, indirect impact, and parties who have not been formally consulted. For AI projects, it also includes anyone whose judgement, role, or data the model substitutes, depends on, or changes.
The three-phase structure
Stakeholder analysis works as a three-phase sequence. Each phase answers a different question, and skipping a phase is the most common reason engagement plans collapse later.
The first phase is identification — who is in the picture at all? The second phase is mapping — which of these stakeholders matter most, and in what way? The third phase is engagement — given how they matter, how will they actually be involved? Identification without mapping produces a long list with no priorities. Mapping without identification produces a tidy diagram that misses the people who will block the project. Engagement without either produces a communications plan that mistakes broadcasting for influence.
Phase 1 — Identification
Identification is a deliberate discovery exercise, not a roll-call of the people already in the project meeting. The bias to fight is visibility bias: project teams tend to identify the stakeholders they already see, which means executives, sponsors, immediate technical colleagues, and whoever is most vocal. The stakeholders who derail AI projects are usually the ones outside that visibility — quiet data owners, line managers whose teams are about to be reorganised, regulatory contacts who only get consulted once a system is nearly live.
A useful identification sweep deliberately covers four overlapping rings.
The inner ring is the project team itself: sponsor, project manager, model developers, MLOps engineers, the immediate business owner. These are easy.
The operational ring is the people whose day-to-day work the AI changes. This is where shadow users live: staff whose roles are altered by the model even though they are not its primary "user". A claims-triage AI changes the work of every claims handler downstream; a hiring screen changes the work of every recruiter; a clinical decision-support tool changes the work of every clinician whose judgement it now overlaps. These stakeholders are routinely missed in project plans because they are not the named users.
The governance ring is the people whose approval the project will need but who are rarely in the project plan as a delivery dependency: data stewards, information security, risk, legal, compliance, ethics reviewers, internal audit. For AI projects this ring matters more than for traditional IT, because each of these functions is increasingly expected to opine on AI specifically. A data steward you did not consult holds an effective veto.
The affected ring is everyone whom the model's outputs reach without being on the project's organisational chart at all: customers, applicants, patients, citizens, suppliers. They almost never appear on the stakeholder list. They almost always determine whether the system is acceptable in production.
Three discovery techniques are worth keeping in the toolkit. Mind mapping starts from the project at the centre and branches outward, asking who else is touched by this branch? — useful for a fast initial sweep. Onion-diagram analysis uses concentric rings (the four above are an example) to make sure peripheral stakeholders are not under-weighted just because they are further from the core. Social network analysis maps the informal influence relationships — who does the chief operating officer actually listen to before a decision? — and is most useful in organisations where the formal hierarchy underpredicts who decides.
Doing this with AI
Once you have your draft stakeholder list, paste it back to the model with this prompt: "Here is my stakeholder list for an AI initiative that does X. Tell me which categories of stakeholder I have probably missed. Specifically check for: shadow users whose work is silently changed, data and platform owners whose approval is required, governance reviewers (risk, ethics, compliance, audit), and affected non-employees such as customers, applicants, or regulators." The model is reliably better at challenging a list than at writing one — let it stress-test your draft.
Phase 2 — Mapping influence and interest
Once the landscape is identified, the next question is which of these stakeholders matter most, and in what way. The most widely used tool here is Mendelow's Power–Interest Matrix (Mendelow, 1991): a 2x2 that places each stakeholder on two axes — power (their ability to affect project outcomes) and interest (the degree to which the project's outcomes affect them).
The matrix produces four quadrants, and each quadrant implies a different engagement strategy. High power, high interest stakeholders are the manage closely group: actively involved in decisions, frequent direct engagement, surfacing of concerns early. High power, low interest are keep satisfied: enough information to remain supportive, but not so much that they disengage; this quadrant is where executive sponsors often sit. Low power, high interest are keep informed: their support and advocacy matter operationally even where their formal authority is limited; this is where many shadow users sit. Low power, low interest are monitor: light-touch communication, but reassessed if the project's scope expands.
The matrix is genuinely useful, but it has two distortions specific to AI projects that are worth naming explicitly.
The first distortion is that interest can flip overnight. A line manager who appears low-interest at scoping becomes high-interest the moment they realise their team is the one being reorganised by the new system. The matrix is not a static document; for AI initiatives it should be revisited at each governance milestone, because the rollout typically reveals interest the scoping conversation did not.
The second distortion is that power in AI projects is often functional rather than hierarchical. A junior data steward with the only access to the training dataset has more effective power over the project than a senior executive in an unrelated function. Risk and ethics reviewers similarly hold power that is invisible on the org chart. Plotting purely by seniority will mislead you; plot by who can stop or unblock the project and you will get a more honest map.
Mitchell, Agle and Wood's Stakeholder Salience Model (1997) is a useful refinement when the matrix feels too coarse. It evaluates stakeholders on three attributes — power, legitimacy (whether their claim is recognised as appropriate), and urgency (whether their issue requires immediate attention) — and treats stakeholders with all three as the most demanding of attention. For most AI projects, however, a well-maintained Mendelow matrix is sufficient; salience adds value mainly when there are competing stakeholder claims that the simple 2x2 cannot resolve.
Did you know?
Stakeholder analysis is now a standard chapter in every project management qualification, but as recently as the 1980s the idea was treated as heretical. R. Edward Freeman's 1984 book Strategic Management: A Stakeholder Approach argued that managers owed obligations to employees, customers, suppliers, communities, and regulators — not only to shareholders. At the time, the dominant view, articulated most famously by Milton Friedman in 1970, held that the social responsibility of business was to increase its profits, full stop. Freeman's framework took roughly two decades to become mainstream. The intellectual battle was not over how to do stakeholder analysis — it was over whether the concept was legitimate at all.
Doing this with AI
Drop your stakeholder map into the model and ask: "For each of these stakeholders, identify the AI-specific event that would flip them from one quadrant to another — for example, what would move this person from low-interest to high-interest, or reveal effective veto power they appear not to have?" Forcing the model to look for state changes is far more useful than asking it to validate the placements you already chose.
Phase 3 — Engagement and the RACI matrix
The map tells you who matters; engagement tells you how each person is actually involved in the work. The most widely used tool is the RACI matrix, which assigns one of four roles to each stakeholder for each significant project activity or decision.
Responsible (R) is the person who does the work. Accountable (A) is the single person who owns the outcome and answers for it; there is one A per activity, no exceptions, because divided accountability is no accountability. Consulted (C) is the person whose input must be sought before a decision is finalised — typically subject-matter experts whose knowledge is required for the decision to be defensible. Informed (I) is the person who must be told once the decision is made, but is not part of making it.
For AI initiatives, the RACI is most useful when it is built around the governance gates of the project rather than around generic delivery activities. The gates that recur on AI projects, and where a clear RACI matters, include: data access and use approval, model approach selection, fairness and bias review, security and privacy review, pilot scope approval, deployment approval, and rollback authority.
For each of these, the project team should be able to answer four questions cleanly: Who does the work? Who decides? Whose input is required for the decision to be valid? Who needs to know once the decision is made? If any of those four answers is "we will figure that out later," the project has a governance hole. Most AI projects that stall in the approval phase stall because one of those four was left implicit.
A note on a common failure pattern: in many AI projects, the same person is named as Responsible and Accountable for nearly every gate — usually the project manager or technical lead. This is almost always wrong. Accountability for fairness review should sit with the function responsible for fairness, not with the person who built the model. Accountability for security review should sit with information security, not with delivery. The RACI is doing useful work only when accountability is distributed across the functions whose remit it actually is.
Project Activity — Complete Part 5: governance and oversight
Open the Module 3 Project workbook and complete Part 5, sections 5.1 and 5.2. Use the stakeholder and governance analysis from this lesson to decide who must be involved, who has authority, and what needs formal oversight.
- In 5.1 Human-in-the-loop oversight design, list the AI decision points in workflow order and choose human-in-the-loop, human-on-the-loop, or human-out-of-the-loop for each one.
- Define override-rate targets, escalation paths, triggers for moving up the oversight ladder, and realistic reviewer workload.
- Use your stakeholder map and RACI to name accountable owners for the key governance gates: data, model, deployment, fairness, security, privacy, pilot approval, rollout, and rollback.
- In 5.2 Ethical, legal and data protection considerations, document the regulatory landscape, data classification, lawful basis, fairness risks, transparency needs, audit trail, subject rights, sign-offs, and the ethical risk specific to your case.
Project Checklist
- Section 5.1 lists all significant AI decision points in workflow order.
- Each decision point has a justified oversight model based on consequence, volume, confidence, and regulatory expectation.
- Override-rate targets are defined and linked to monitoring.
- Escalation paths explain who arbitrates, what is logged, and who reviews patterns.
- Reviewer workload is realistic enough to avoid rubber-stamping.
- Section 5.2 names the laws, regulations, data categories, and sign-offs relevant to this initiative.
- Fairness, transparency, audit, and subject-rights considerations are specific to my project.
- Accountable owners are named for governance gates and sign-offs.
⏭️ Up next — Lesson 2: With the stakeholder map and engagement structure in place, Lesson 2 turns to what happens inside the people and the organisation once the change actually arrives — change implementation and resistance management. How to plan for adoption, anticipate where it will be hardest, and build the structures that make the change stick.