
Map influence, then set the comms cadence
Stakeholder Management: Analysis, Engagement and the Communication Plan
Identify, analyse and engage stakeholders: power/interest and salience models, an engagement assessment matrix, a communication plan, tactics for resistance and a worked example.
On this page
- Who counts as a stakeholder?
- The stakeholder management process
- Analysis model 1: power / interest grid
- Analysis model 2: salience (power, legitimacy, urgency)
- The engagement assessment matrix
- Building the stakeholder register
- The communication plan
- RACI, used sparingly
- Handling resistance
- Worked example: a finance system replacement
- Measuring stakeholder engagement
- Common mistakes
Projects rarely fail on technical grounds. They fail because someone with the power to stop them was surprised, ignored, or engaged too late. Stakeholder management is the discipline of finding those people early, understanding what they need, and deliberately moving them to the level of engagement the project requires.
The PMBOK® Guide (8th edition) treats stakeholders as a performance domain in its own right: effective engagement is an outcome you plan for and measure, not a by-product of sending status reports.
Who counts as a stakeholder?
Anyone who can affect the project, is affected by it, or believes they are. The last group matters most — perceived impact drives behaviour as strongly as real impact.
| Group | Typical members | What they usually care about |
|---|---|---|
| Sponsor & governance | Sponsor, steering committee, portfolio board | Benefits, risk exposure, reputational impact |
| Delivery | Team members, vendors, contractors | Clear priorities, realistic workload, decisions on time |
| Users & operations | End users, support teams, line managers | Disruption, training, whether it makes their job easier |
| Enablers & gatekeepers | Finance, legal, security, procurement, architecture | Compliance, approvals, standards, audit trail |
| External | Customers, regulators, unions, partners, the public | Service impact, obligations, fairness |
The stakeholder management process
- 1Identify — brainstorm with the sponsor and team, review the charter, org charts, contracts and past lessons learned. Keep asking: who else will notice when this changes?
- 2Analyse — record each stakeholder's interest, influence, attitude, and what they want from the project. Prioritise using a grid or salience model.
- 3Plan engagement — decide the desired engagement level for each priority stakeholder, the gap from today, and the actions and communications that close it.
- 4Engage — run the plan: one-to-ones, workshops, demos, reviews and decision forums. Listen as much as you broadcast.
- 5Monitor — revisit the register at each phase gate and after major events. Engagement drifts; new stakeholders appear when the project changes shape.
Analysis model 1: power / interest grid
| Low interest | High interest | |
|---|---|---|
| High power | Keep satisfied — concise briefings, no surprises, escalate only decisions they own | Manage closely — co-create decisions, regular one-to-ones, early sight of bad news |
| Low power | Monitor — general communications, watch for changes in interest | Keep informed — regular detail, involve in testing and feedback, often your best advocates |
Analysis model 2: salience (power, legitimacy, urgency)
The salience model asks three questions: does this person have power to influence the project, a legitimate claim on it, and urgency — a time-sensitive need? Stakeholders with all three are 'definitive' and demand immediate attention. Those with power and urgency but no legitimacy are 'dangerous' — for example a senior manager outside your governance trying to redirect scope — and need careful handling through the sponsor.
The engagement assessment matrix
For each key stakeholder, mark where they are today (C) and where you need them to be (D). The gap is your engagement plan.
| Stakeholder | Unaware | Resistant | Neutral | Supportive | Leading |
|---|---|---|---|---|---|
| Finance director | C | D | |||
| Head of operations | C | D | |||
| Customer service team | C | D | |||
| IT security lead | C | D | |||
| Sponsor | C | D |
Building the stakeholder register
- Name, role and organisation — and who they listen to.
- Interest in the project and what success looks like to them.
- Influence: formal authority, informal influence, and control of resources or approvals.
- Current and desired engagement level, with the reason for the gap.
- Key concerns, likely objections and known history with similar projects.
- Engagement owner — the person on the team who holds the relationship.
- Preferred channel and frequency, plus the next planned interaction.
The communication plan
| Audience | What they need | Format | Frequency | Owner |
|---|---|---|---|---|
| Steering committee | Status vs. baseline, risks, decisions required | One-page report + meeting | Monthly | PM |
| Sponsor | Early warnings, escalations, options | One-to-one | Weekly | PM |
| Delivery team | Priorities, blockers, changes | Stand-up / planning | Daily / per sprint | PM / scrum master |
| Affected users | What is changing, when, and how it affects them | Email, intranet, demos | Fortnightly, increasing near go-live | Change lead |
| Gatekeepers (security, finance) | Artefacts for approval with lead time | Review submissions | Per gate | Workstream lead |
RACI, used sparingly
- Responsible — does the work. Can be several people.
- Accountable — answers for the outcome. Exactly one person, always.
- Consulted — two-way input before the decision.
- Informed — one-way notification after it.
Use RACI for decisions and deliverables that cross team boundaries, not for every task. A RACI with 200 rows is never read; one with the 15 decisions that cause arguments is used every week.
Handling resistance
| What you see | Likely cause | What to do |
|---|---|---|
| Missed meetings, slow approvals | Low priority or quiet disagreement | One-to-one conversation; ask what would make this worth their time |
| Repeated objections on detail | Fear of loss — status, headcount, control | Name the concern openly; involve them in shaping the solution |
| Going around you to the sponsor | Lack of trust in the project or PM | Agree escalation paths with the sponsor; brief them first, together |
| Public support, private blocking | Political conflict with another stakeholder | Surface conflicting goals to the sponsor as a decision, not a complaint |
| Frontline workarounds after go-live | Solution does not fit real work | Observe the work, fix root causes, recruit champions from the group |
Worked example: a finance system replacement
Illustrative scenario. A mid-sized company replaces its accounts-payable system. The finance director (high power, initially resistant) fears month-end close will slip during cutover. The AP team (high interest, low power) worry about job changes. IT security must approve the cloud vendor.
- 1The PM met the finance director one-to-one, listened, and added 'no impact to month-end close' as an explicit success criterion and cutover constraint.
- 2Two AP clerks joined design workshops and user testing; one became the super user and ran peer training.
- 3The security review was started in week two, not at go-live, with a named owner and a date on the critical path.
- 4The communication plan moved from monthly updates to weekly 'what changes for you' notes in the six weeks before cutover.
- 5Result: the finance director moved from resistant to supportive and chaired the go/no-go meeting; the AP team adopted the new process with no rollback.
Measuring stakeholder engagement
- Movement on the engagement assessment matrix between phase gates.
- Decision turnaround time — days from request to decision by governance.
- Attendance and participation in workshops, demos and reviews.
- Pulse surveys or short sentiment checks with key groups.
- Escalations and complaints raised outside the agreed channels.
- Post-go-live adoption: usage, workarounds and support tickets by group.
Common mistakes
- Identifying stakeholders once at kick-off and never revisiting the list.
- Treating communication as engagement — sending reports is not the same as listening.
- Managing only up: pleasing the steering committee while users disengage.
- Hiding bad news from high-power stakeholders until it is unavoidable.
- Letting the PM own every relationship instead of assigning engagement owners.
Related PMI standards & templates
External resources on pmi.org — links open in a new tab. Some require PMI membership.
PMBOK-aligned templates for this topic
Editable Word and print-ready PDF downloads — no sign-up required.
- Project charter template →A PMBOK-aligned project charter template with a section-by-section walkthrough, a filled-in example and the sign-off block sponsors actually ask for.
- Project status report template →A PMBOK-aligned project status report template with a RAG summary, milestone and budget tables, a filled-in example and the decisions block sponsors actually read.
- RACI matrix template →A PMBOK-aligned RACI matrix template with a section-by-section walkthrough, a filled-in example and the one-accountable-owner rule that stops responsibility arguments.
- Stakeholder register template →A PMBOK-aligned stakeholder register and engagement plan template: power/interest grid, current versus target stance, and the channel and cadence for every group.
The PM Delivery Toolkit turns everything in this guide into fill-in templates — $25, one payment.
Get five PM habits that quietly save projects
Baselines, critical path discipline, RAID logs that people read, range estimating and status packs sponsors act on — sent straight to your inbox, free.
One email, no spam, unsubscribe any time.
Discussion
Share how you applied this in practice, ask a question, or add a tip for other readers.
Loading comments…