Identify Stakeholders Before They Identify Themselves
Every project eventually has a stakeholder who introduces themselves. It happens at a gate review, or three days before go-live, or in a forwarded email from somebody two levels above the sponsor asking why they are only now hearing about this. What they bring is hardly ever new information to the organisation. It was sitting there in month one for anybody who had gone looking.
Identification gets treated as an initiation task, because that is where it sits in most templates, and the register produced at initiation is usually accurate about the people the sponsor already deals with. The gap is in the question that produced it. Asking who is involved returns the people who attend meetings. Asking who this will affect, and who can stop it, returns the ones who turn up uninvited in month five.
Start from what the project will change
Follow the thing being delivered the whole way through its life. Somebody specifies it, somebody builds it, somebody approves it, somebody operates it on a wet Tuesday in eighteen months, somebody maintains it, somebody pays its running costs out of a budget that is not yours, and somebody will be audited on it. Every one of those is a stakeholder. The operating and maintaining pair are the ones most often absent from a register written at initiation, because neither of them exists yet in the project's world.
Then ask who can say no. That question finds the stakeholders holding formal rights: a regulator, a works council, a safety authority, a data protection officer, a landlord, a planning authority, a union with an agreement covering working arrangements, an accreditation body. They rarely surface in a stakeholder brainstorm because they have no interest in your project as such. They have an interest in a category of thing your project happens to be an instance of, and the first they hear of it is when it reaches them.
Ask everyone you have already identified who else will care. This works because people know their own organisation's wiring far better than any chart records it, and it costs thirty seconds at the end of a conversation you were having anyway. Two or three names come back, and one of them is usually somebody you would not have reached by any other route.
Last, read what the organisation already knows. A closure report or lessons record from a comparable project names the people who objected late last time, which is precisely the list of stakeholders that project failed to identify early. Organisational memory is a poor system and a cheap one.
The points where the list goes stale
Section 2.5.2 of the PMBOK® Guide Eighth Edition carries Identify Stakeholders as a named process and treats it as work that continues through a project rather than a task discharged at the start. In practice that means a short set of moments when the list is worth reopening.
A change of scope changes who is affected, which is obvious and still gets missed, because the change is assessed for cost and schedule and nobody assesses it for who it newly touches. A change of development approach does the same. Moving to incremental release puts the operations team in the project from month three when they were expecting month fourteen, and they will not have been staffed for it.
A new phase or a new site brings a local population who were irrelevant while the work was somewhere else. A change of sponsor replaces the relationship the whole register was built around and deserves a full review. An external shift, a new regulation or a change in who owns a supplier, can create a stakeholder overnight who did not exist when the project started.
None of these reviews takes long. Twenty minutes at a phase boundary with the same four questions covers it, and doing it before commitments are made is far cheaper than doing it afterwards, because a stakeholder found late arrives with a position already formed and a reason to be annoyed.
Five months and a works council
A consultancy was designing a shared finance service for a manufacturer with plants in four countries. The stakeholder list came from the client sponsor and was decent as far as it went: the group finance director, the four site finance directors, the IT director, two systems integrators, the internal audit lead.
In month five the design reached the part where twenty-two roles at two of the sites changed shape. At that point the works councils at both sites held a formal right to be consulted, which they had held all along. The consultation ran eleven weeks alongside a design phase that could not be signed off, and cost the programme its planned January start.
Nobody had hidden anything. The question that would have found them was who can stop this, asked in the first fortnight, and the answer was available from the site HR managers. The site HR managers were not on the list either, because the engagement had been framed as a finance project and HR is not finance.
The recovery is worth noting too. Once the councils were properly engaged they were constructive, and a good part of those eleven weeks went on the position they had formed about a project that had reached month five without speaking to them. The consultation itself was never the expensive part.
For a PMP® candidate, a situation's stakeholder list is best treated as incomplete until the effects have been traced. A project where an unexpected party objects late is seldom asking for an escalation; it is asking what identification work was never done, and the fitting response is to go and do it. That instinct comes from working through situations where the missing party was discoverable in the description all along, and a structured PMP exam preparation course deals in exactly those.
Walk the delivery chain with a colleague who had no hand in writing the plan, and half an hour covers it. Name the thing being delivered, then say out loud who specifies it, approves it, operates it, maintains it, funds it and inspects it, and who is entitled to refuse it. Most projects produce two names nobody had. Finding them in week two costs a phone call. Finding them in month five costs a quarter.
Interested in going further?
The stakeholders who damage a project are usually the ones holding a formal right that nobody thought to ask about. Omega's PMP® Exam Preparation works through situations where the missing party is sitting in the description, waiting to be found.
Identify Stakeholders is one of the named processes carried inside the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A132: The PMBOK 8 Stakeholders Performance Domain: What It Really Covers
A133: Stakeholder Management vs Stakeholder Engagement
A134: Power/Interest Grid vs Salience Model
A135: Stakeholder Power Is Not the Same as Engagement
A136: Why Hostile Stakeholders Still Need Engagement
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
