Stakeholder Mapping Is Only the Start
A stakeholder map gets built the way most project artefacts get built: in a room, by the project team, out of what they already know. It is usually competent work, and it is a set of hypotheses about people who were not in the room. What it is worth depends almost entirely on what happens in the fortnight afterwards.
What usually happens is nothing. The map goes into the project folder, gets opened twice, and is still saying in October what somebody guessed in March.
A map is a set of guesses
Two things make the first version unreliable, and neither is a failure of effort.
The information is second-hand. Positions get inferred from reputation, from something said in a meeting eighteen months ago, from a previous project, and from the reasonable assumption that a person's interests follow their job title. All of that is usable and none of it is evidence. A director whose remit covers the affected area is assumed to be interested; a director who has just been handed a different priority by the chief executive is not.
The map records a position at one moment. People's positions move for reasons that have nothing to do with the project: a reorganisation, a bad quarter, the arrival of a regulator, a new boss with a view. A map with no date on it and no review point is a photograph presented as a description.
The three things that should follow
Section 2.5.2 of the PMBOK® Guide Eighth Edition treats the stakeholder processes as connected work, and the connection that matters most is between the analysis and what anybody does with it. Three things follow a map.
Test it. The only way to find out whether an entry is right is contact with the person in it. A short conversation with each of the eight or nine people who matter will correct about half the map, and the corrections are specific and useful in a way no amount of internal discussion ever is. Somebody recorded as supportive turns out to support the objective and object to the timing, which is a different problem with a different answer.
Convert it. Every row should produce a named action with an owner and a date, or an explicit note that nothing is needed. A map generating no actions is an artefact, and the exercise that produced it was a workshop about people. The actions are usually small: a call, a visit, a request for somebody to attend one meeting, an offer to brief a team.
Date it and set a review. A quarter is about the useful life of a stakeholder assessment on a project of any size, and rather less during a reorganisation. Attach the review to something already in the calendar, because a standalone stakeholder review is the first thing cancelled in a busy month.
Who can read it
A stakeholder map is a document assessing named colleagues, and project teams routinely write things in one that they would never say out loud. Obstructive. Difficult. Unlikely to engage. Needs managing. All of those appear in real registers, attached to real names, on shared drives whose permissions nobody has looked at.
Two disciplines are worth adopting. Write every entry as though the person might read it, which forces specificity: "has said he cannot release staff before the audit closes in June" is more useful than "resistant" and carries no risk at all if it is seen. And keep the analysis wherever the project team keeps its sensitive material, with the access list checked, because a version pinned up in a glass-walled room is legible to the floor outside it.
Two phone calls in a change programme
A retail bank was running a programme to change how branch staff handled a class of customer complaint, touching about two hundred branches. The stakeholder map came out of a two-hour workshop and looked thorough: twenty-six entries, each assessed for influence and current position.
Two of them were wrong in ways that mattered, and a phone call corrected each. The head of operations was marked supportive, on good grounds, since he had sponsored a similar change two years earlier. He was supportive of the objective and firmly opposed to the timing, because the proposed go-live fell in the same six weeks as a regulatory submission his team owned. Nobody in the workshop had known the submission existed.
A regional director was marked low interest, because the programme was a central initiative and he had shown no involvement in it. Half the affected branches sat in his region, and the reason he had shown no involvement was that nobody had told him. He turned out to be the most useful person on the map and stayed useful for the rest of the programme.
Both calls ran to about twenty minutes. The workshop that produced the map took two hours of six people's time, which was a reasonable investment. The forty minutes that made it accurate was the better one.
For a PMP® candidate, the useful reading is that analysis is an input and never an outcome. A project with a thorough stakeholder register and a stakeholder problem is pointing at the gap between the two, and a fitting response is contact rather than further analysis. Ask what was done with an assessment, not how good the assessment looks. Practising on situations where the documentation is impeccable and the outcome is poor is a standing part of a structured PMP exam preparation course.
Take the map and write one action against each of the top eight rows this week, with a name and a date on it. Then put twenty minutes in the diary with each of those eight people inside a fortnight, with no agenda beyond finding out whether the entry is right. Most project managers come out of those eight conversations with two corrections, one stakeholder nobody had listed, and a piece of information that changes the plan.
Interested in going further?
An accurate stakeholder map is worth having and worth about an hour of anybody's time; everything that follows it is where the value sits. Omega's PMP® Exam Preparation works through situations where the analysis is sound and nothing has been done with it.
The PMBOK® Guide Eighth Edition sets out the stakeholder processes and how each one feeds the next.
Ad · Amazon affiliate link.
References
A133: Stakeholder Management vs Stakeholder Engagement
A141: Tailoring Stakeholder Engagement for Different Contexts
A135: Stakeholder Power Is Not the Same as Engagement
A134: Power/Interest Grid vs Salience Model
A132: The PMBOK 8 Stakeholders Performance Domain: What It Really Covers
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
