A stakeholder is anyone who can affect a project or is affected by it, and PMI's definition adds anyone who believes themselves affected. This is a much wider group than the people who approve the funding. It takes in the team whose system the project will call, the operations group that inherits what is built, the reviewer who will read the audit trail and the people whose working day changes on the morning of release. PMBOK 8 gives stakeholders a performance domain of their own, and the examination tests the subject in every domain, because most scenario questions turn on what a particular person needs.
Engagement is what happens after the stakeholders are found. Knowing somebody exists is worth little on its own, and the practice is really about understanding what each person needs, where they stand today and what would move them. The sections below cover how stakeholders are identified, the two ways they are analysed, the register that holds the result and why the ones found late cost the most.
Identification runs the length of the project
The first pass at a stakeholder list happens early and is always incomplete. The obvious names arrive quickly, meaning the sponsor, the functional managers whose staff are assigned and whoever turned up to the kickoff. What the first pass cannot contain is everybody the project has not yet reached.
Those people appear as the work moves. An integration step reveals a team that owns an interface nobody documented. A procurement step reveals a legal reviewer with a firm position on where data may be held. Identification therefore runs for the life of the project, and the habit worth building is to ask at every planning point who has become relevant since the last one.
Power, interest and attitude
Once a person is on the list, the familiar analysis sorts them by the power they hold over the project and the interest they take in it. Four groups fall out of that, and each suggests a different level of effort.
The axes rank the attention somebody is worth this quarter and say nothing about how much the person matters. The bottom right corner is worth a second look, because interested people with little formal power generate most of the traffic and are easily mistaken for the ones who decide.
Power and interest leave out the thing that usually decides the outcome, which is attitude. A powerful and interested stakeholder who wants the project to succeed is the best asset it has, and the same person set against it is the largest risk on the register. Recording attitude beside each name changes what the analysis is for.
The grid is a conversation starter. Its value is that it makes a small group say out loud where they think somebody sits, and the disagreement that follows is the useful part. Two people who place the same director in different quadrants have found something worth settling before it becomes a surprise.
A position on the grid is temporary. Interest tracks whether the project has reached anything the person owns, so the quiet director in the top left corner belongs in the top right corner the week the project's change touches their system. This is why the analysis is repeated at intervals and why it is dated.
The stakeholder engagement assessment matrix
A more practical model puts each stakeholder on a scale running from unaware to leading, which PMI calls the stakeholder engagement assessment matrix. It describes what somebody currently does about the project, which is easier to observe and easier to agree on than what they feel about it.
| Level | Where the person stands | What tends to move them up |
|---|---|---|
| Unaware | Has no knowledge of the project, or none of what it will change for them | A briefing framed in the terms of their own work |
| Resistant | Knows about it and does not want it, or wants a different version of it | Finding out what they are protecting, then answering that |
| Neutral | Aware of it, and neither helping nor obstructing | A reason the outcome matters to something they own |
| Supportive | Wants it to work and will say so when asked | A request specific enough to act on |
| Leading | Spends their own effort and credibility on it | Enough information to stay accurate in public |
What makes the scale useful is recording two positions, the level somebody occupies now and the level the project needs from them. Most people have no reason to be leading, and dragging everybody up the scale spends effort on those whose neutrality costs nothing.
Where the two differ there is an action to take.
| Stakeholder | Current | Desired | What the gap calls for |
|---|---|---|---|
| Finance director | Unaware | Supportive | Brief them in budget terms before the quarterly review |
| Operations lead | Resistant | Neutral | Ask what the handover will cost their team, and answer it |
| Security architect | Neutral | Supportive | Move the design review forward while an objection is still cheap |
| Sponsor | Supportive | Leading | Ask for the one decision only they can make |
| Regional manager | Supportive | Supportive | Nothing, which is the reason for recording both columns |
Read down the last column and the result is a stakeholder plan. Read down the two middle columns and the result is the argument for it, which is the part that survives somebody asking why the project is spending a week on briefings.
The stakeholder register
Both analyses are recorded in the stakeholder register, which carries names, roles, interests, assessed influence, the current and desired engagement levels and whatever classification the analysis produced. Some of that is sensitive, and a candid note about somebody's attitude belongs with the few people who need it.
What keeps the register alive is a review attached to something that already happens, such as a monthly steering meeting. Reorganisations move where power sits, people leave and a stakeholder who was supportive in March can be resistant by September because a different priority landed on their team.
A register that has gone three months without an edit has usually gone three months without being opened, and the two are worth telling apart before anybody concludes the stakeholder picture is stable.
Stakeholders found late
A stakeholder found in the first month costs a conversation. The same person found after the design is fixed costs rework, and the bill grows with everything built on the assumption they would have corrected.
Familiar examples are the security architect who appears at the readiness review, the works council that has to be consulted before a process changes and the country manager whose market carries a rule the others do not share. Each of them is being entirely reasonable and each of them is late, and lateness is a property of the identification process and never of the person.
When somebody does surface late, the question worth asking is what would have found them sooner. Sometimes the answer is a question nobody thought to ask, and sometimes it is that the project kept a group at a distance because engaging them looked slow.