The Stakeholder Map That Survives Contact With the Project

A stakeholder map lists who can stop the work, what each one can stop, and where I know that from. A blank row to copy, three filled in from public sources.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

One line in a published help centre article put a warehouse goods-in lead on my stakeholder map: returned items are inspected when they arrive, and the inspection can change the outcome. That role approves nothing, and no public document I could find puts it in an approval flow. Approve refunds from photographs, which is the change I recommend, and the inspection starts landing after the money has gone. A stakeholder map is a list of the people who can stop the work, what each one of them can stop, and where I know that from.

In short

• A row earns its place when it finishes one of three sentences: can approve X, can veto Y, decides Z in practice.
• Every row carries a source, and "my inference, unconfirmed" counts as one, as long as it is written down instead of implied.
• The row that costs you month two is the one that loses something when the project succeeds, and no influence grid measures loss.
• The blank row is below, ready to copy, followed by three rows built only from public sources, so you can check every claim in them.

The grid takes ten minutes. Two axes, four quadrants, every name dropped somewhere on the square, and whoever lands top right gets a weekly meeting. I have drawn it, I have sat in workshops that produced it, and it has never once predicted the thing that later went wrong.

The axes are not the problem. The problem is that the grid answers a question nobody was going to ask. It tells me how much attention a person deserves. It never tells me what happens when that person says no.

Those are different questions and only one of them has consequences. "High influence, high interest" is a temperature reading. "Can refuse to sign the release" is a fact about the project I am standing in. The grid tells me how loudly to talk to someone. It never tells me whose no ends the conversation.

What turns a name into a row?

Take anyone on your map and finish one of these three sentences about them.

• Can approve X. Their yes is required. Without it, nothing ships.
• Can veto Y. Their no stops it, and enthusiasm everywhere else does not route around them.
• Decides Z in practice. Nothing on the org chart says so. They hold the outcome anyway, because the work passes through their hands.

If none of the three fits, you have recorded an interest rather than a decision right. Interests are worth knowing. They are not what the map is for.

The third sentence earns the artifact. Approvals and vetoes are usually written down somewhere, so a diligent reader finds them. The decision that happens in practice is written down nowhere, it is held by whoever the work physically passes through, and it is the one that turns up late.

Where do you know that from?

The second thing a row needs is evidence: where you know the first part from.

I fill it in because the stakeholder map is where I guess most and admit it least. Attitudes, fears, what somebody "obviously" wants - it all feels like knowledge, and most of it is a story I assembled from two meetings and a tone of voice.

Three answers are acceptable there. A document and the section it sits in. A sentence somebody said, and roughly when. Or "my inference, unconfirmed". The third is not a failure. Silence is, because silence is how a guess gets promoted to a fact by the second reader.

The last column does the same job from the other side. It holds the sentence a reviewer would use against the row, written down by me before they get to say it. It takes a minute per row and it is the cheapest way I know of finding out which rows I have grown attached to.

The blank row, and three filled in

Copy this. Seven columns, one row per person, hints in the brackets.

Here is the same table with the worked case in it. The rows come from the returns case published here: damaged-delivery refunds at a mid-size online retailer, built entirely from public sources - a published returns policy, the help centre, and complaint threads anyone can read. There was no engagement and no client, and nobody inside the company was asked anything, which is why the evidence column has to work hard. Two tags do the sourcing: [POLICY] is stated in the published returns policy, [HELP] in a help centre article.

Sixty to ninety minutes for a map this size, once the reading is done. Most of it goes into the last three columns, which is the honest way of saying that the first four were quick because they were half invented.

Half of that evidence column says "my inference, unconfirmed", and the version without those words would be worse. An inference marked as one is a question with somewhere to land. An inference typed as a fact is a trap set for whoever reads the document after me. The fix is not deletion, it is a line in the open questions register with an owner, a date, and a fallback for when the date passes.

The missing names work the same way. Each one stays an open question rather than turning into a plausible invention. An empty owner slot with a question against it reads as diligence. An invented name reads as something else, and it comes apart in the first interview, when somebody asks how you met her.

Which row loses something?

The head of customer care is the row that writes itself. That department owns the published promise, the change rewrites that promise, and on projects shaped like this one the owner of the promise is usually in the room from the first workshop. That last part is a guess about a room I have never been in. This case has no workshops in it, only documents.

The goods-in lead is the row I nearly did not write. The role appears in no approval flow that anyone outside the company can see. The published process still hands it the parcel, the judgement about whether its condition matches the claim, and the choice between the shelf and the scrap bin. That is a decision the published policy never mentions.

And the change I am recommending makes that position worse. Approving the refund from photographs, before the item arrives, moves every condition dispute past the point where the money is gone. Today the sequence protects that role by accident. My change removes the accident and replaces it with nothing. That is the sort of thing you want to find in your own document rather than in a meeting.

This is what the influence grid cannot do. On its axes the row is low influence and, until the first dispute, low interest. Bottom left, monitor, minimal effort. Every property the grid measures says ignore it, and the one property it does not measure says that under the change I am recommending, that inspection lands on a refund customer care has already communicated.

Read your own map with one question: which row loses something? If every row gains and nobody loses, you mapped the kick-off invite list, not the organisation. The resistance you meet in month two then arrives with no name on it, and you call it culture.

What to do with this on Saturday

Take a map you already have, from a real project or a case you built yourself. Add three columns and delete nothing.

In the first, write the sentence that person can say to stop or change the work. In the second, write where you know that from, including "my inference, unconfirmed" wherever it is true. In the third, write the objection a reviewer would raise against the row, in their words rather than yours.

Two things usually happen. Some rows turn out to be an audience rather than stakeholders and move to a list at the bottom. And one or two names appear that were never there, because the exercise makes you walk the process end to end and name every pair of hands.

The stakeholder map is the first of the six artifacts I look for in a portfolio, and the one people most often submit as decoration: twelve boxes copied off an org chart, ten minutes of work, nothing in it that could be wrong. Six rows with a decision right and a source behind each one take an afternoon and are hard to fake. The full worked case, with the register and the open questions behind these three rows, is in the Proof Pack.

The map is finished when a stranger can check every row in it without asking me a single question.

All field notes · The portfolio guide · More in The Case File