Communication Planning: Who Needs What, and How Often
Turning "we should keep people updated" into a concrete plan for who hears what, how, and when.
Intermediate
TopNotchNote
Notes that matter
why this needs a plan at all
Without a deliberate plan, project communication defaults to whoever happens to ask and whatever a PM remembers to send — which reliably produces gaps ("did anyone tell finance the launch date moved?") and noise (everyone cc'd on everything "just in case"). A communication plan takes the stakeholder list already built during stakeholder analysis and turns it into concrete decisions: who needs which information, in what format, how often, and through which channel.
three communication methods
- Push — sent out to recipients (email updates, status reports). Efficient for reaching many people at once, but there's no guarantee it was read or understood.
- Pull — recipients retrieve it themselves (a shared dashboard, an internal wiki, a project intranet page). Good for large volumes of reference information that not everyone needs at once.
- Interactive — real-time exchange in both directions (meetings, calls, chat threads). The most reliable for anything complex, sensitive, or likely to generate questions, but doesn't scale to a large audience.
Matching the method to the message matters: a routine weekly status update is a natural fit for push; a decision that affects someone's team directly usually deserves interactive communication, not a line in a newsletter.
matching frequency to the audience
The power/interest grid from stakeholder analysis maps directly onto communication frequency and depth — a stakeholder who needs to be "managed closely" gets frequent, detailed, often interactive updates; one who just needs to be "kept informed" gets a lighter, less frequent push update. Sending everyone the same level of detail wastes the time of people who need less, and under-serves the few who need more.
| Audience | What they need | Format | Frequency |
|---|---|---|---|
| Sponsor | Budget, schedule, major risks | Interactive review | Biweekly |
| Core team | Task status, blockers | Interactive standup | Daily |
| Adjacent teams | Milestones affecting their work | Push email | At each milestone |
| Wider organization | High-level progress | Pull (wiki page) | Updated monthly |
a short example
A team building a feature across three time zones (California, London, Bangalore) plans around the fact that almost no meeting time overlaps all three. Day-to-day coordination shifts to pull (a shared async status doc everyone updates at the end of their own day) and push (a written weekly summary), reserving the one weekly window where two of the three regions overlap for genuinely interactive discussion — decisions that actually need real-time back-and-forth, not status that could've been written down.
practical notes
Write the plan down as a simple table (audience, content, format, frequency, owner) and keep it visible — a plan that only exists in the PM's head doesn't survive them going on vacation.
Distance, time zones, and language differences are real barriers, not just inconveniences to push through — leaning toward async, written communication (which can be translated, re-read, and doesn't require simultaneous availability) usually serves distributed teams better than defaulting to more live meetings.