Project communication is a design problem before it is a writing problem. The work is deciding who needs what information, when they need it, in what form and how often, and most of the failures blamed on poor communication are really failures to have answered those questions.
Who needs what, and how often
Start from the decision each person has to make rather than from what the project would like to report. A sponsor deciding whether to keep funding the work needs progress against the plan and the risks that would change the answer. An operations manager needs to know what is arriving and when their staff must be trained. A supplier needs their own dependencies and dates. The underlying facts are shared and the selection is not, which is why one report circulated to everybody serves nobody particularly well.
Frequency follows the same logic. Information arriving faster than somebody can act on it turns into noise, and the recipient who has learned to skim you is the same recipient who will skim the message that mattered.
The form matters as much as the frequency. A director with four minutes wants the conclusion, the decision being asked of them and the two facts that support it, in that order, and the supporting detail available underneath for the one time in five they go looking for it.
Push, pull and interactive
Push communication is sent to named recipients, meaning reports, memos, emails and formal notices. It confirms that information was distributed and confirms nothing about whether it was understood, so it suits records, obligations and routine updates.
Pull communication is placed somewhere and retrieved by whoever wants it, such as a repository, a dashboard or a knowledge base. It scales to large and varied audiences and moves the effort to the reader, which is right for reference material and wrong for anything that has to reach a particular person by a particular time.
Interactive communication is a real exchange between two or more people, in a meeting, a call or a conversation. It is the only one of the three that confirms understanding, because the other party can ask the question that reveals they took a different meaning, and it costs the most per person reached.
| Method | What it is | What it suits | Where it fails |
|---|---|---|---|
| Push | Sent to named recipients, such as a report, a memo, an email or a formal notice | Records, obligations and routine updates, where evidence of distribution matters | Anything contested, because it confirms that something was sent and says nothing about how it landed |
| Pull | Placed somewhere and retrieved by whoever wants it, such as a repository, a dashboard or a knowledge base | Reference material, and large varied audiences who each want a different part of it | Anything that has to reach a named person by a named time, because the effort sits with the reader |
| Interactive | A real exchange between two or more people, in a meeting, a call or a conversation | Negotiation, contested change, and anything where the other party has to be able to object | Scale and record, because it costs the most per person reached and leaves nothing behind unless somebody writes it up |
The common error is pushing something contested. A significant scope change announced by email is a push method carrying an interactive problem, and the silence that follows is the sound of people forming positions in private.
The pairing that works is interactive first and push afterwards. Hold the conversation with the people whose objection would matter, then send the note that records what was agreed, so the written trail exists and nobody learned the news from it.
Channels grow faster than the team
The number of potential communication channels among n people is n(n-1)/2.
Five people have ten channels, ten people have 45, and twenty people have 190.
| People | Channels | Channels the next person adds |
|---|---|---|
| 3 | 3 | 3 |
| 5 | 10 | 5 |
| 8 | 28 | 8 |
| 10 | 45 | 10 |
| 15 | 105 | 15 |
| 20 | 190 | 20 |
| 30 | 435 | 30 |
The third column is the one to read. Every person joining a team of twenty brings one person's capacity and twenty new pairs who might need to reach each other, so the coordination cost of a hire rises with the size of the group already there.
That growth is why large projects need structure small ones can skip. It is why representatives speak for groups, why a communications plan exists at all, and why adding people to a late project makes it later.
The practical response is to reduce the number of channels that have to carry traffic rather than trying to service all of them. Written decisions do this work, because a decision recorded once removes the need for the twenty conversations that would otherwise transmit it. So does a named owner per topic, which turns a group of twenty into one person to ask.
Informing and engaging are different jobs
Informing moves facts to people. Engaging changes what those people do, think or support, and it requires something to come back from them.
A weekly report nobody responds to is informing. A conversation in which a stakeholder's objection changes the plan is engaging. Projects routinely mistake the volume of the first for the presence of the second, then discover at a governance review that a director who received every report has been holding a position nobody knew about.
The test is whether anything ever comes back. Where no stakeholder has changed anything the project did in two months, what is running is a broadcast, however comprehensive the distribution list looks.
The plan is a working artefact
A communications plan records who receives what, by which method, how often, who produces it and why it exists. Written for a governance gate and never reopened, it is documentation. Used properly, it is what you check when a stakeholder says they were not told, and it is where a new team member learns who has to hear about a slip.
The why column is the one that decays first and the one worth keeping honest. A report exists because somebody makes a decision with it, and once you write that reason down the reports that have outlived their decision become obvious.
It changes as the project does. New stakeholders appear, phases shift what matters, and a report that was essential during design has no readers during deployment. The most useful review question is which of these reports anybody would notice the absence of, and the answer usually retires at least one of them.