Stakeholder analysis — why the list can be complete and the analysis still worthless

Most stakeholder analyses are complete and worthless all the same. They are put together during the kickoff week, fill a table with twenty rows, get filed away — and the moment the first escalation hits, it turns out that the person who can stop the whole thing isn't even on the list.

This is rarely down to carelessness. It is down to the analysis answering the wrong question: it records who is involved. What would actually be useful is knowing who can block the project and why they might want to.

What a stakeholder analysis is meant to achieve

Stakeholders are everyone who can influence the project or is affected by it. The second half of that sentence is routinely skipped over — and that is exactly where the people sit who will later slow things down: the works council, the data protection officer, the team whose workflow changes without anyone having asked.

The analysis has three jobs, and only the first is done reliably:

1. Identify — who is in the picture at all?
2. Assess — how much influence does someone have, and how much does the project affect them?
3. Derive — what does that mean for how you work together?

Without the third step, the analysis is a list of names with colours.

The matrix everyone uses

The most widespread tool is the power-interest grid, which goes back to Aubrey Mendelow: a four-quadrant matrix of power and interest. High power and high interest means close engagement; high power and low interest means keep them satisfied without overloading them; and so on.

The grid is useful, but it has a weakness that gets expensive in day-to-day project work: it captures a state, not a behaviour. Interest shifts the moment the project actually reaches someone. A person with low interest in week two can be the loudest critic by week twelve — not because their stance has changed, but because that is when they first grasped what was being planned.

The more nuanced model by Mitchell, Agle and Wood therefore adds a third dimension: alongside power and legitimacy, urgency. Anyone who combines all three attributes is the case where delay costs the most.

For practical purposes, a simpler rule usually does the job: next to each person, add a column for what they gain if the project succeeds and what they lose. Anyone who cannot fill that column has not analysed the person, merely noted them down.

Where a language model genuinely helps

The benefit lies where you wouldn't expect it. Assessing individual people is the part a model cannot take over — and, for data protection reasons, should not. The part before that, all the more so.

The completeness check. You describe the project in a few sentences — no names — and ask: which roles are typically affected by a project of this kind and are regularly overlooked? The answer reliably includes the things nobody thinks of during the kickoff: the works council, data protection, procurement, the external auditor, the department that maintains the legacy data. This is the most valuable application, because it addresses the most common mistake.

Framing interests. Turning a position into an underlying interest is tedious and lends itself well to guided support. "Procurement is against the new system" is a position. "Procurement is responsible for a running framework agreement, the cancellation of which would put them on the hook for an explanation" is an underlying interest — and only the second gives you something to work with.

Preparing for conversations. Drafting questions that reveal a stance rather than merely confirm it. This, too, is a matter of wording, not assessment.

The boundary that runs differently here

With most project documents, the question is whether a language model delivers usable results. With a stakeholder analysis, a second question comes first: whether you may feed it in at all.

A stakeholder analysis contains names, functions and judgements about identifiable people — right down to notes like "opposed to the project". This is personal data, and the judgement is the most sensitive part of it. Entering it is permissible only where two things are in place: a legal basis under Article 6 GDPR and — where the provider acts as a processor — a contract under Article 28 GDPR. If either is missing, the input is not permissible, regardless of how useful the result might be.

The workable separation is: roles yes, people no. "Head of Procurement" instead of the name, "works council" instead of the chair. For the completeness check and for framing interests, the role is entirely sufficient — it is in fact the better input, because it doesn't tempt the model into statements about individuals. Mapping names to roles happens afterwards, in your own records.

This is not a formality to be ticked off. It is the point at which the difference between "we use AI" and "we use AI responsibly" actually becomes visible — and precisely the competence Article 4 of the EU AI Act presupposes: the provision obliges providers and deployers to ensure a sufficient level of AI literacy among the people operating such systems on their behalf.

An approach that works

1. Describe the project without names. Scope, affected areas, expected change.
2. Ask about roles — which are typically overlooked? Place your own list alongside, don't replace it.
3. Map names to roles, offline, in your own records.
4. Fill two columns per person: what they gain, what they lose. Where you can't, a conversation is still outstanding.
5. Set a review date. A stakeholder analysis that is never reopened after the kickoff was effort without return.

The check in four questions

• Does each person have a note on what they gain if the project succeeds and what

they lose?

• Is there someone on the list who can stop the project without formally deciding

it?

• Are those affected captured — not just those involved?
• Is there a date on which the analysis will be looked at again?

Four yeses do not mean the analysis is correct. They mean it will offer something in the event of conflict — and that is the only moment anyone ever looks at it.