Lesson 2 — Communication and Stakeholder Management¶
At a glance
- Module: 10 — Team Resources & Communication
- Level: Intermediate
- Estimated time: 40 minutes
- Example project: the university admission portal and the public service information system
Learning objectives¶
By the end of this lesson you should be able to:
- Explain where communication fails, using the sender–channel–receiver model.
- Choose between interactive, push, and pull communication for a given message.
- Build a communication plan and a stakeholder engagement plan.
- Report status honestly, including bad news, in a form a decision-maker can act on.
Prerequisites¶
Introduction¶
Most project failures are described afterwards as communication failures. That phrase is usually accurate and almost never useful, because it says nothing about where the communication failed or what to change.
This lesson breaks communication into its parts so failures can be located, and covers the two documents that prevent most of them: a communication plan, and a stakeholder engagement plan.
1. Where communication breaks¶
A simple model is enough to diagnose most problems.
Sender → encode → channel → decode → Receiver ⟶ feedback
Noise can enter at every stage, and each stage has a characteristic failure:
| Stage | Failure | Typical cause |
|---|---|---|
| Sender | The message was never formed clearly | The sender had not decided what they wanted |
| Encode | Meaning lost in wording | Jargon, ambiguity, assumed context |
| Channel | Wrong medium for the message | A decision sent by email; a status update in a meeting |
| Decode | Receiver interpreted differently | Different background, language, or incentives |
| Feedback | None, so the error is invisible | No confirmation that understanding occurred |
The last row is the most expensive. Communication without feedback is not communication; it is transmission, and you have no evidence it arrived.
Two practical rules follow. Write down decisions. And ask for the understanding back, not agreement: "can you tell me how you'd describe that to your team?" reveals a misunderstanding that "does that make sense?" never will.
2. Choosing a channel¶
Communication is a tool with properties, not a virtue.
| Mode | Example | Good for | Poor for |
|---|---|---|---|
| Interactive | Meeting, call, pair discussion | Ambiguity, negotiation, conflict | Wide distribution; record keeping |
| Push | Email, announcement, status report | Confirmed distribution, decisions for the record | Understanding complex or contested things |
| Pull | Wiki, repository, dashboard, backlog | Detail on demand, self-service | Urgent or unread messages |
The most common error is using interactive mode for things that should be written (repeating the same status to each stakeholder) and push mode for things that should be interactive (announcing a significant change that people will resist).
Written artefacts also solve the accountability problem: a decision recorded in a document can be found, quoted, and revisited. A decision in a conversation lasts as long as memory.
3. The communication plan¶
A communication plan answers, for each audience, five questions:
| Audience | What they need | When | How | Owner |
|---|---|---|---|---|
| Sponsor | Cost and schedule variance, decisions required | Fortnightly | One-page report + 30-minute call | Project manager |
| Delivery team | Priorities, blockers, decisions | Daily, asynchronous | Shared board | Project manager |
| Clinic/academic staff | What is changing for them, when | Monthly, plus milestones | Short briefing | Business analyst |
| IT operations | Deployment needs, environment changes | Two weeks before each release | Written request | Tech lead |
| Students (users) | What to expect, when | Twice only | Notice on the portal | Communications officer |
Two disciplines make it work. First, match cadence to decision speed: reporting monthly on something decided weekly means decisions wait. Second, do not let the plan grow: every recurring report is a standing cost, and reports nobody acts on should be abolished explicitly, since silence is otherwise taken as a signal of something wrong.
4. Stakeholder engagement¶
Identify stakeholders, then assess them on two axes: power (can they affect the outcome?) and interest (do they care?). The grid suggests a stance.
| Low interest | High interest | |
|---|---|---|
| High power | Keep satisfied | Manage closely |
| Low power | Monitor | Keep informed |
Position alone is not enough: people move as the project progresses, and today's uninterested party is often tomorrow's blocker. Engagement levels are useful in the same way:
| Level | Response |
|---|---|
| Unaware | Inform, simply and early |
| Resistant | Understand the objection; resistance usually has information in it |
| Neutral | Give them a reason to engage |
| Supportive | Use them — they can advocate where you cannot |
| Leading | Keep them informed; they are spending their credibility on the project |
A resisted change is often a design that has not yet answered a real concern. Treating resistance as obstruction wastes the cheapest requirements input available.
5. Reporting status¶
A status report exists so somebody can make a decision. It is not a record of activity.
- Lead with variance, not with progress: what has changed against the baseline, and why.
- Give the decision required, if any, and by when.
- Separate facts ("the interface specification is 8 days late") from assessment ("this pushes integration past the freeze") from request ("approve a two-day extension or descope the export").
- Never let a red status appear for the first time at the moment the project fails. A trend is more actionable than a cliff, and the trend is visible earlier.
Key terms¶
| Term | Meaning |
|---|---|
| Interactive communication | Real-time exchange between participants |
| Push communication | Sent to recipients without them requesting it |
| Pull communication | Available for recipients to retrieve when needed |
| Communication plan | Audiences, content, cadence, channel, and owner |
| Power/interest grid | A stakeholder assessment tool |
| Engagement level | From unaware through to leading |
| Variance | The difference between planned and actual |
| Baseline | The approved version against which variance is measured |
Worked example¶
Task: plan communication for the illustrative university admission portal, which replaces a paper-based process used by academic departments. Assumptions are invented for teaching.
Step 1 — Identify stakeholders and assess them.
| Stakeholder | Power | Interest | Stance |
|---|---|---|---|
| Registrar (sponsor) | High | High | Manage closely |
| Admissions office staff | Medium | High | Manage closely — their work changes most |
| Academic department heads | High | Low until results | Keep satisfied, then inform intensively |
| IT operations | Medium | Low | Keep informed; needed for deployment |
| Applicants (users) | Low | High seasonally | Keep informed |
| Internal audit | High | Low | Monitor; engage before launch |
Step 2 — Anticipate resistance before building. Department heads are low-interest now but high-power later, and their process is being removed. The cheapest response is early involvement in the rules that affect them — which is also the best source of correctness for the rules. This is the resistance-as-information principle applied deliberately, and it moves a stakeholder from Monitor to Supportive.
Step 3 — Design the communication plan.
| Audience | What | When | How |
|---|---|---|---|
| Registrar | Variance and decisions required | Fortnightly | One page plus 30 minutes |
| Admissions staff | Changes to their workflow | Monthly, plus a hands-on session | Workshop and written guide |
| Department heads | Rules affecting them; go-live date | At rule definition and one month before | Structured meeting, then notice |
| IT operations | Environment and deployment needs | 2 weeks before each release | Written request |
| Applicants | What to expect | One month before, and at launch | Portal notice |
Step 4 — Choose channels deliberately. The workflow change for admissions staff is contested and concrete: it gets interactive workshops, not a broadcast email. The go-live date for applicants is fixed and simple: pull — a page they can find — not a push announcement that will be missed.
Step 5 — Report honestly. In week 6 the interface to the student records system slips. The report does not say "slightly behind"; it says: "Interface delayed by 8 days. Impact: integration testing moves into the freeze window; launch unaffected if we descope the alumni export. Decision required by Friday." Fact, assessment, request.
Step 6 — Note the cost of the plan. Six recurring communication activities consume real people's time. Two are cut at review because nobody acts on them. Abolishing them explicitly stops their absence being read as a problem.
Common misconceptions¶
“More communication is better”
Unnecessary communication has a cost: it competes with the work it reports on, and it teaches people to skim. Match cadence to the decisions being made, and remove reports that no one acts on.
“Email is communication”
Email is transmission. Without confirmation that the message was understood, and without a decision recorded somewhere durable, the communication has not occurred.
“Resistance is obstruction”
Resistance frequently carries information about a requirement nobody gathered. Understanding the objection is cheaper than overriding it, and usually improves the design.
Practical activity¶
Write the plans. For one example project:
- Identify at least six stakeholders and place them on the power/interest grid.
- For the highest-power, lowest-interest stakeholder, write the action that will keep them engaged before they become a blocker.
- Build a five-row communication plan with audience, content, cadence, channel, and owner.
- Justify one channel choice by contrasting it with a rejected alternative.
- Write a three-sentence status report on a delay: fact, assessment, request.
What "good" looks like: a stakeholder identified as a future blocker with a concrete pre-emptive action, a channel choice justified against its alternative, and a status report where the decision required is unmistakable.
Self-assessment¶
- Why is missing feedback the most expensive failure in the communication model?
- Give one message best sent by push and one best sent by pull, and justify each.
- A key stakeholder is resistant to a workflow change. What is the first thing to do?
-
Rewrite as a reportable item: "Testing is going a bit slower than planned."
-
Apply it — e-commerce launch. Two weeks before launch you learn the payment provider integration will be late by an unknown number of days. Marketing has already emailed retailers a launch plan built on the date. Your sponsor suggests waiting until the delay is confirmed “so nobody worries unnecessarily”.
Hint: A strong answer names the channel for this message and what the communication plan should already have decided.
Show answers
- Because it hides every other failure. Without confirmation that understanding occurred, a decoding error stays invisible until it shows up as wrong work, and by then the cost is in the delivery rather than the message.
- Push: a project decision that must reach named people and be on record, such as a change to an approved interface. Pull: detailed reference material such as environment setup instructions, which most people do not need and which changes often.
- Find out what the objection is. Resistance usually encodes a real concern — extra work, a lost capability, or a risk nobody has priced — and gathering it is both cheaper than overriding it and likely to improve the change.
- "Testing of the reporting module is 3 days behind the baseline, because two fixtures were specified late. Impact: the module misses the review window; release date unaffected if the fixtures are available by Monday. Decision required by Monday." Fact, cause, impact, request.
- Tell the affected people now, factually: the event is known, its impact is knowable within a range, and marketing has a plan that depends on the date, so waiting converts a schedule problem into a credibility problem — and it takes the decision out of the hands of the people who own the priority. Choose the channel deliberately: unwelcome news with consequences goes through an interactive channel (a short conversation with the sponsor, marketing and support), with the same content recorded in the status report so the record is consistent; a wiki update alone is the wrong channel. What the communication plan should already have settled is audience, content, cadence, channel, owner — and the escalation criteria that decide when bad news is shared, so the timing is agreed before the emotion is present.
Summary¶
- Communication fails at a specific stage; diagnosis requires naming the stage rather than saying "communication broke down".
- Interactive, push, and pull channels suit different messages — and the wrong choice is a common and avoidable failure.
- A communication plan names audience, content, cadence, channel, and owner, and should be pruned rather than expanded.
- Stakeholders are assessed by power and interest and move over time; resistance usually contains information.
- Status reports lead with variance and end with the decision required.
Further learning¶
- Module 11 — Metrics, Monitoring & Control covers variance analysis and earned value.
- A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute — communications and stakeholder engagement.
- Peopleware: Productive Projects and Teams, Tom DeMarco and Timothy Lister — on communication overhead and team space.
Next¶
You have completed Module 10. Continue to Module 11 — Metrics, Monitoring & Control.