Stakeholder Management
A stakeholder is anyone who can affect your project or be affected by it. The ones who show up in month four with a legitimate objection were always stakeholders — the only thing that changed is that you now know.
In short
- Find them early. A stakeholder discovered in month four brings requirements priced at month-four rates.
- Sort by power and interest to decide how much attention each one gets — not how important they are as people.
- The dangerous quadrant is high power, low interest. They aren’t watching now; they will be at approval time.
- Engagement means a named cadence and format per stakeholder, not “keep them in the loop”.
Finding them before they find you
Most stakeholder lists are too short, and they’re short in a predictable way: they contain the people who asked for the project and omit the people who will have to live with it.
Six prompts that surface the missing ones:
- Who pays? The sponsor, and whoever holds the budget if that’s someone else.
- Who uses it? Not their manager — the people who will touch the thing daily. They rarely appear on the initial list and they determine whether it succeeds.
- Who has to approve something? Security, legal, procurement, architecture, data protection. Any group with a veto is a stakeholder, however uninterested they seem today.
- Who runs it afterwards? The team who inherits the result at handover. Involving them at the end is how you get a handover that gets refused.
- Whose work changes? Adjacent teams whose process shifts because of yours. They’re affected, so they’re stakeholders, even though nobody asked them.
- Who is outside the building? Customers, vendors, partners, regulators, auditors.
One more source, worth its own line: ask the team. Someone who has worked in this area before usually knows exactly which group will object, and often assumes you already know. The question “who do you think is going to have a problem with this?” is startlingly productive in week one.
Sorting by power and interest
The quadrant that catches people out
High power, low interest is where projects get ambushed. Security, legal, procurement, architecture review — groups with the ability to stop you and, right now, no particular reason to be paying attention.
Their interest is not permanently low. It becomes high at precisely the moment you need their approval, which is usually the moment you have least slack. And their questions at that point are the same questions they would have asked in week one, when answering them would have been a design decision rather than a rebuild.
The move is to convert them into a scheduled dependency: find out what their review requires, how long it takes, and book it now. That single action — row 5 in the diagram — removes an entire genre of late-project disaster.
Deciding what each one gets
“Keep them informed” is not an engagement plan, because it doesn’t say what, how often, or by whom. A workable entry has four fields:
| Field | Example | Why it matters |
|---|---|---|
| What they need | “Confidence the date holds” | Different from what they ask for, which is usually detail |
| Format | Three bullets, no attachment | The wrong format is the same as no communication |
| Cadence | Weekly, Friday | Predictability is most of what builds trust |
| Owner | A name | Otherwise it happens for three weeks and stops |
Match the depth to the quadrant. A sponsor needs decisions and exceptions, not a task list. A user group needs to see the thing and react to it, not read a status report. A compliance reviewer needs the specific artefact their process requires, on a date they can plan around.
What actually builds trust
Stakeholder management has a reputation for being about influence and politics. In practice, the behaviours that work are unglamorous and repeatable:
Be boring and regular
An update every Friday, including the Fridays with nothing to report, is worth more than a brilliant deck once a quarter. Silence gets filled with assumptions, and the assumptions are rarely generous.
Deliver bad news first
A stakeholder who hears about a slip from you, early, treats you as a source. One who hears it from somebody else treats every later update as marketing.
Ask what they actually need
Directly, in the first conversation. It takes two minutes, and it frequently reveals that the elaborate report you were about to build is not what anyone wanted.
Close the loop when they input
Tell people what happened to their feedback, including when the answer is no and why. Feedback that vanishes teaches people to stop giving it, or to escalate instead.
Common failures
- Mapping once. Stakeholders change as a project moves through its phases. The map is a living document, reviewed at the same rhythm as the risk register.
- Confusing loudness with power. The person emailing daily may have no authority at all, while the person who will decide has said nothing yet.
- Only managing upward. Careful attention to executives and none to the people who will use the thing produces a project that is approved and then ignored.
- Treating a group as one stakeholder. “The finance team” has at least three different interests in it. Name individuals.
- Engagement without authority to change anything. Consulting people and then ignoring all of it is worse than not asking. If a decision is already made, say so.
How this looks in AB
In AB Projects, stakeholders are first-class members of the project rather than a separate audience you ship reports to. Add them as members — full access or read-only as fits the role — and they see the same tasks, status and deadlines the team sees. Not a curated summary assembled the night before, but the actual thing.
That has a real consequence worth naming: it changes what a status update is for. When anyone can see the state of the work at any time, the update stops being a data transfer and becomes interpretation — what changed, what it means, what decision is needed. Which is the only part that was ever worth a stakeholder’s attention.
The map itself lives on a pinned page in the project Wiki, next to the work it describes. Engagement happens where stakeholders already are: Adaptive Cards posted to the linked Teams or Slack channel announce status changes and surface decisions inline — complete with the task ID and a deep link back — so a busy executive can respond in seconds without opening another tool. Mentions ping the right person on the right thread, and the change-history tab answers “when did we agree to that?” without anyone reconstructing it from memory.
Terms used on this page
- Stakeholder
- Anyone affected by the project or able to affect it. The definition is deliberately wide, because the expensive ones are the people you didn’t count. More →
- Power–interest grid
- A two-by-two sort of stakeholders by their ability to affect the project and their attention to it, used to decide how much engagement each receives. More →
- Stakeholder register
- The list of stakeholders with their interest, influence, what they need and who owns the relationship. Alive if reviewed; a document if not. More →
- Sponsor
- The stakeholder who funds the project and decides trade-offs the team cannot. Always in the manage-closely quadrant, by definition. More →
- Engagement plan
- Per stakeholder: what they need, in what format, how often, and who owns sending it. The output of stakeholder analysis, and the part usually skipped. More →
- Steering committee
- A standing group of senior stakeholders who take decisions the project manager cannot. Useful on large projects; overhead on small ones. More →
Related reading
4.3 Communication Planning
Turning the engagement column into a rhythm that runs without anyone remembering it.
3.1 Defining Project Scope
Where unmapped stakeholders show up: as assumptions nobody wrote down.
2.1 Project Initiation
Where the first stakeholder list is drawn up, and why the sponsor has to be a person.