Communication Planning
“Communicate more” is not a plan, and it isn’t even usually the fix. Projects fail from information reaching the wrong people at the wrong time in the wrong form — which is a design problem, and design problems have solutions.
In short
- A communication plan says who hears what, how often, through which channel, from whom. Four columns and a page.
- Tailor the message to what each audience has to do with it — not to their seniority.
- Deciding who does not need to hear something is half the value.
- Automate the routine flow so human attention goes to interpretation and decisions.
Communication is a system, not a virtue
The instinct when coordination goes wrong is to add a meeting. Sometimes that’s right. Usually it addresses the symptom — someone didn’t know something — without touching the cause, which is that nobody decided in advance whose job it was to tell them.
A plan replaces that assumption with a small number of explicit decisions. It takes an hour to write and it removes the entire category of failure that begins “I thought you were telling them.”
The same fact is three different messages
The bottom panel is the one people find uncomfortable, and it’s the most important. Telling everyone everything is not transparency — it is offloading the filtering work onto the reader, and the predictable result is that they stop reading. Attention spent on updates that don’t concern you is attention unavailable when one does.
Building the plan
One table, one page. If it needs more, the project has too many independent interfaces and the fix is structural rather than editorial.
| What | Who | When | Where | Owner |
|---|---|---|---|---|
| Status & exceptions | Sponsor | Weekly, Friday | Card in the project channel | PM |
| What changed today | The team | Continuous | On the task itself | Whoever changed it |
| Blockers & decisions | The team | Daily, 10 min | Standing call | PM |
| Working demo | Users, support | Fortnightly | 30-minute session | Team lead |
| Milestone reached | Everyone | On the event | Automatic notification | — |
| Date at risk | Sponsor first | Same day, always | Direct message, then card | PM |
Three things that row set gets right and most plans get wrong. The owner column is filled in with names, so nothing depends on collective memory. The last row exists at all — most plans cover routine reporting and say nothing about the one communication that matters most. And several rows are continuous or automatic rather than scheduled, which is where a tool should be doing the work.
Choosing a channel
Channels differ along two axes that actually matter: whether they demand attention now, and whether the message survives being missed.
Immediate and permanent
A comment on the task; a message in the project channel. The default for project communication: it interrupts appropriately and it is still there in month five when someone asks why.
Immediate and ephemeral
A call, a corridor conversation. Fastest way to resolve something genuinely ambiguous — and the decision then has to be written somewhere, or it didn’t happen.
Deferred and permanent
The Wiki, the plan, the scope document. For things people need to look up rather than be told. If you find yourself re-explaining something, it belongs here.
Sits awkwardly across all four and is read by nobody with a full inbox. Reserve it for people outside your tooling and for things that need a formal record.
The most common channel error is putting a decision in an ephemeral place. Six weeks later there is no record, two people remember it differently, and both are being honest.
Push what changes, pull what persists
A simple discipline that removes a surprising amount of noise:
- Push events — something changed, something is blocked, a decision is needed. These have a time value and expire.
- Pull states — what the current plan is, who owns what, what the scope says. These should live somewhere anyone can look, not be pushed repeatedly to people who might need them.
Get this backwards and you produce the two classic failures at once: weekly reports full of unchanged information nobody reads, and genuine changes buried inside them.
Meetings that earn their cost
A meeting is the most expensive channel available — its cost is the number of attendees multiplied by its length, and it’s paid whether or not anything happens. It’s worth it for exactly three things: deciding something that needs several people, resolving a disagreement, and building the shared understanding that makes the rest of the week’s async communication work.
It is not worth it for transferring status, which a tool does better and asynchronously. If your status meeting consists of everyone reading out what a board already shows, you have a meeting compensating for a system nobody trusts — and the fix is to make the board trustworthy.
The habits that carry it
- Be boringly regular. Every Friday, including the Fridays with nothing to report. Predictability is most of what people mean by trust.
- Lead with the bad news. Burying a slip in paragraph four teaches people to read you sceptically forever.
- Say what you don’t know. “We don’t yet know if this affects the date; I’ll know Thursday” is a complete and useful update.
- Close the loop. When someone raises something, tell them what happened to it — including when the answer was no.
- Write for the person who wasn’t there. Most of your communication will be read by someone catching up. A message that assumes yesterday’s context excludes them.
How this looks in AB
In AB Projects, the communication plan stops being a document people forget and becomes the way the work runs.
The plan itself lives as a pinned page in the project Wiki — the who / what / when / where table above. But most of the day-to-day flow happens without anyone remembering to do it: Adaptive Cards posted to the linked Teams or Slack channel announce status changes the moment they happen, complete with the task ID and a one-tap deep link, so the “milestone reached” and “what changed today” rows largely take care of themselves.
For everything needing a human nudge, mentions on tasks reach the right person on the right thread rather than broadcasting to a channel. AI assistants connected through the MCP server can post scheduled summaries too, and they carry a clear robot signature so attribution stays unambiguous — which matters, because an update whose author is unclear is an update nobody acts on.
The change-history tab on every task records who said what and when. That turns “was it communicated?” from a matter of recollection into something with an answer — useful in a retrospective, and considerably more useful in the meeting where two people remember a decision differently.
Terms used on this page
- Communication plan
- An agreement about who receives what information, how often, through which channel and from whom. One page, or it won’t be followed. More →
- Asynchronous communication
- Messages that don’t require both parties at once — comments, documents, recorded updates. Cheaper in attention and better for anyone in another timezone. More →
- Information radiator
- A always-visible display of project state — a board, a dashboard — that people pull from rather than being told. Replaces most status reporting. More →
- Escalation path
- The agreed route a problem takes when it can’t be resolved where it arose, and how fast. Agreed in advance, or it’s improvised under pressure. More →
- Status report
- A periodic summary of progress, risks and decisions needed. Valuable when it interprets; wasted when it merely lists what a tool already shows. More →
- Stakeholder
- Anyone affected by the project or able to affect it. The communication plan exists to serve this list. More →
Related reading
6.3 Reporting Progress
What goes in a status report, and how to make it worth someone’s attention.
4.2 Stakeholder Management
The input to this page: who the audiences are and how much attention each warrants.
5.0 Project Tools
The views that let people pull the project’s state instead of being told it.