Stakeholder Mapping for Technical Changes

Stakeholder mapping is taught as a plotting exercise — interest on one axis, influence on the other, four quadrants, done. The plotting is the part that has never caused a problem.

Aldermoor Health's API rename had a stakeholder map. Eleven rows, plotted carefully, reviewed at kickoff. It was a good map of the people on it.

The launch surprised four groups: the support team, whose customer documentation referenced the old endpoint by name; the marketing team, using it in a published tutorial; a partner whose integration the account manager had forgotten existed; and the analytics team, whose dashboards keyed on endpoint names and quietly went flat.

None of the four were mis-plotted. All four were absent. A stakeholder map fails on a missing row, essentially always — and no amount of care with the axes catches one.

The grid is the output; discovery is the work

The interest-versus-influence grid does a real job: it forces you to treat people differently, which stops you from either broadcasting everything to everyone or handling only the loudest.

But it can only sort rows you already have. Once the list exists, plotting takes ten minutes and mistakes are cheap to correct — put Finance one quadrant too low and someone tells you. Leave Finance off entirely and nobody tells you, because the mechanism that would have told you is the thing you skipped.

So the question that matters isn't how do I plot these. It's how would this person find out if I didn't tell them? If the honest answer is "when it breaks", they belong on the map regardless of where they'd plot.

The test you can run: take your current stakeholder list and, for each row, name how they'd learn about the change if you dropped them. Then ask who else would learn about it that way. Those are your missing rows.

Eight questions that surface the rows you'd miss

"Who should we tell?" reliably produces three or four groups. Asking the question eight different ways produces eight to fifteen, and the ones past the obvious list are where the surprises live.

Ask	Typical answer people forget	How to find it
Who uses it?	Internal users, not just customers	Access logs
Who depends on it?	Downstream systems, other teams' jobs	Caller query, 90 days
Who runs it?	On-call, infra, whoever gets paged	The rota, not the org chart
Who governs it?	Security, compliance, audit, legal	Ask whether it's ever been in an audit
Who pays for it?	Finance, budget owner, procurement	Whoever'd notice the invoice change
Who decides about it?	The person who can actually stop it	The A in your RACI
Who reports on it?	Analytics, BI, someone's spreadsheet	Ask who owns dashboards touching it
Who supports its users?	Support, success, training, docs	Search the help centre for its name

The reporting row is the one most consistently missed and the one that fails most quietly — a dashboard doesn't error when its data stops arriving, it just shows a flat line that somebody eventually notices in a monthly review.

The test: run all eight questions on your next change and count the groups. Under eight, you stopped early; the discipline is asking "who else?" past the point where it feels productive.

Systems and people are two different searches

There's a real division of labour here, and collapsing it is how teams believe they've done this work when they haven't.

Impact analysis finds systems — what calls you, what reads your data, what holds an assumption about your behaviour. It's a query, it's reliable, and it doesn't care what anybody remembers.

Stakeholder mapping finds people — and its input is that list of systems. Every dependent system has an owner, and the mapping step is walking the list asking who owns this, and how do I reach them.

Which makes the most useful output of the exercise the gap: a system with no reachable owner. Aldermoor found three, and the forgotten partner integration was one of them. A dependency you cannot contact is worse than one you missed, because you'll discover it at exactly the same moment either way and have nobody to call.

The test: take your dependents list and put a name against every entry. The blanks are your finding — and they're worth escalating before the change, not after.

Engagement level is a promise, not a label

Once the rows exist, each gets one of four levels. These behave exactly like RACI letters: they're commitments, and the honest ones are shorter than the polite ones.

• Inform — one-way. They read it, they can't change it. This is most of the map and there's nothing wrong with that.

• Consult — you ask before deciding, and their answer can change the outcome. If it can't, this is Inform with extra meetings.

• Involve — they're in the working group, reviewing deliverables, in the room.

• Co-decide — they can say no and the no holds.

The failure is inflation: marking someone Consult because Inform feels dismissive. That's a promise you've already decided not to keep, and the cost lands on them — a meeting invitation, a document to read, an expectation that their input mattered. Doing it once teaches them their input doesn't count, and that lesson is what turns an objection into silence, which is more damaging than never asking.

Same test as the RACI cell: if this person objects, does anything change? No means Inform.

The test: count your Consults. More than two or three per change and either you're not honouring them or every decision is waiting on four people.

When to skip it

The map costs half an hour, which is cheap but not free, and running it on everything trains people to fill it in without thinking:

• The change is contained in one team with no interface change. Code review covers it, and the stakeholder list is the people in the room.

• It's a standard change. The mapping happened once, at promotion, and the change hasn't varied since.

• You already have a current map for this system. Reuse it and spend the time checking whether it's stale instead.

• Nobody outside the team could be surprised. That's the whole criterion, and it's worth answering honestly rather than reflexively.

Where it always earns its cost: interface changes, anything customer-visible, anything touching money or regulated data, and any first-of-its-kind change — because a first-of-its-kind change is precisely the one where nobody's intuition about who's affected has been calibrated yet.

The test: could this change reasonably surprise someone outside the immediate team? Yes means map it. No means skip it and move on.

What to change this week

Don't draw the grid. Do the discovery.

Run the eight questions against your next cross-team change and write the list — just the list, unplotted. Then put a name and a contact against every row, and treat the blanks as the deliverable. That's where the forgotten partner and the ownerless dashboard live.

Plotting takes ten minutes afterwards, and if you want the artifact itself, the stakeholder map template has the grid and the columns already laid out.

Then set a revisit: kickoff, midpoint, and a week before launch. Maps go stale in a specific way — the rows stay right and the people change, so the map looks fine while pointing at someone who moved teams in March.

Aldermoor's API rename map has nineteen rows now. Four of them came from the reporting question, which nobody had ever asked. Two rows are still blank, and both are flagged in the change request as accepted risk — which is a different thing from not knowing.