Stakeholder Communication
Projects do not fail because of technology. They fail because of people — miscommunication, misaligned expectations, unresolved conflicts, invisible stakeholders who emerge at the worst moment with the power to block everything. Communication is the connective tissue of project management. Without it, a technically perfect project delivers the wrong thing to the wrong people at the wrong time.
Simon Sinek's insight applies directly: people don't buy what you build, they buy why you build it. A status report that says "Sprint 7 complete, 34 points delivered" communicates nothing to an executive who needs to know "Are we going to make the Q3 launch?" The same information, framed differently, serves different audiences. This skill covers the frameworks for identifying who needs what, building communication plans, running effective meetings, resolving conflicts, and managing organizational change.
Agent affinity: sinek (pedagogy/leadership, "Start With Why"), brooks (organizational dynamics, communication overhead)
Concept IDs: bus-stakeholder-theory, bus-corporate-governance, bus-business-ethics, crit-argument-construction, crit-evidence-evaluation
Stakeholder Identification and Mapping
The Power/Interest Grid
Classify stakeholders along two dimensions:
- Power: Ability to influence project decisions, resources, or outcomes
- Interest: How much the stakeholder cares about the project's outcome
| | High Interest | Low Interest | |---|---|---| | High Power | Manage Closely — Key players. Regular engagement, involve in decisions. | Keep Satisfied — Dangerous if surprised. Periodic high-level updates. | | Low Power | Keep Informed — Enthusiastic supporters or worried users. Regular updates, feedback channels. | Monitor — Minimal effort. Available information if they seek it. |
Worked Example — E-Commerce Platform Rewrite
| Stakeholder | Power | Interest | Strategy | |---|---|---|---| | VP of Engineering | High | High | Manage closely — weekly 1:1, involved in architecture decisions | | CFO | High | Low | Keep satisfied — monthly cost summary, flag budget variances early | | Customer support team | Low | High | Keep informed — sprint demos, early access to staging | | Legal/compliance | High | Medium | Keep satisfied — notify on data handling changes, PII flow reviews | | End users (beta group) | Low | High | Keep informed — changelog emails, feedback survey per release | | Marketing team | Medium | Medium | Keep informed — feature announcements 2 weeks before launch | | Infrastructure team (DevOps) | Medium | High | Manage closely — daily standups, shared Kanban board | | Board of directors | High | Low | Keep satisfied — quarterly executive summary |
Hidden stakeholders. The most dangerous stakeholders are the ones you did not identify. Common hidden stakeholders: security/audit teams (veto power over production deployment), data protection officer (GDPR implications), downstream service owners (API contract changes), executive assistants (gatekeepers to executive time).
Salience Model (Mitchell, Agle, Wood)
For more nuanced classification, the salience model uses three attributes:
- Power: Ability to impose will
- Legitimacy: Perceived appropriateness of the stakeholder's involvement
- Urgency: Time sensitivity of the stakeholder's claim
Stakeholders with all three attributes are definitive — they require immediate, full engagement. Stakeholders with two are expectant — they will escalate if ignored. Stakeholders with one are latent — they may emerge as expectant if conditions change.
Communication Planning
The Communication Matrix
For each stakeholder or stakeholder group, define:
| Element | Question | |---|---| | Who | Which stakeholder or group? | | What | What information do they need? | | When | How frequently? Triggered by what events? | | How | Channel: email, meeting, dashboard, Slack, document? | | Why | What decision or action does this communication enable? |
Worked Example — Communication Plan
| Who | What | When | How | Why | |---|---|---|---|---| | VP Engineering | Sprint progress, blockers, risks | Weekly (Friday) | 15-min 1:1 + written summary | Resource allocation, escalation decisions | | CFO | Budget vs. actual, forecast to complete | Monthly | Email with 1-page dashboard | Budget approval, investment decisions | | Dev team | Sprint goals, dependencies, blockers | Daily | 15-min standup | Synchronization, impediment removal | | Customer support | Upcoming features, known issues | Per sprint | Demo + release notes | Prepare for customer inquiries | | End users (beta) | New features, bug fixes | Per release | Changelog email + in-app notification | Feedback collection, adoption | | Board | Project status (RAG), strategic alignment | Quarterly | 2-slide executive summary | Strategic governance |
Channel Selection
Rich channels (face-to-face, video call) for: ambiguous topics, conflict resolution, relationship building, bad news.
Lean channels (email, documents, dashboards) for: routine updates, reference information, audit trails, asynchronous consumption.
Brooks's communication overhead. In The Mythical Man-Month, Brooks showed that communication paths grow as n(n-1)/2 for n people. A team of 5 has 10 communication paths; a team of 10 has 45. This is why Scrum limits team size and why communication planning becomes critical as organizations scale. Every person added to a project increases communication cost quadratically.
Status Reporting
RAG Status (Red/Amber/Green)
The simplest and most widely understood status format:
- Green: On track. No action needed.
- Amber: At risk. Mitigation underway. Needs attention.
- Red: Off track. Requires immediate intervention or escalation.
RAG rules:
- Never report Green when you know Amber is coming next week. Report Amber now with "trending toward Green" or "trending toward Red."
- A status that has been Amber for 4 consecutive weeks is effectively Red — the mitigation is not working.
- Red is not a failure; it is an honest signal. Punishing Red reports guarantees dishonest Green reports.
Worked Example — Sprint Status Report
Project: Commerce Platform Rewrite
Sprint: 7 of 12
Date: 2026-04-10
Overall: AMBER
Schedule: GREEN — 34/36 points delivered (94%)
Scope: AMBER — Payment gateway integration blocked by vendor API delay.
Vendor committed to API delivery by April 15. If missed, checkout
feature slips to Sprint 9. Contingency: mock API for continued
development.
Quality: GREEN — 0 P1 defects. 3 P3 defects in backlog. Test coverage 87%.
Budget: GREEN — $142K spent of $200K budget. Forecast: $185K at completion.
Key decisions needed:
1. Approve contingency plan for payment API delay (VP Engineering by April 12)
2. Confirm beta user group expansion to 500 users (Product Owner by April 14)
Risks surfaced this sprint:
- R07: Payment API documentation incomplete (NEW, Score: 12)
- R03: Staging environment — RESOLVED (provisioned April 8)Earned Value Management (EVM)
EVM provides objective, quantitative project status by comparing planned work to completed work and actual cost.
Core metrics:
- PV (Planned Value): Budgeted cost of work scheduled. What you planned to have done by now.
- EV (Earned Value): Budgeted cost of work performed. What you actually have done, valued at planned rates.
- AC (Actual Cost): Actual cost of work performed. What it actually cost to do what you did.
Derived metrics:
- SPI (Schedule Performance Index) = EV / PV. SPI < 1 means behind schedule.
- CPI (Cost Performance Index) = EV / AC. CPI < 1 means over budget.
- EAC (Estimate at Completion) = BAC / CPI. Forecasts total project cost based on current efficiency.
Worked example.
| Metric | Value | Interpretation | |--