How to Write a Project Communications Plan (With a Reporting Cadence That Sticks)

Write a communications plan by listing every stakeholder group, deciding what each one actually needs to know, then fixing the channel, format, frequency and named owner for each. The plan is a table, not an essay. Set the reporting cadence last, and set it at a frequency you can sustain for the whole project.

This is for whoever ends up owning project comms. It covers the steps, the fields, the weekly beat everything hangs off, and why most cadences stop around week three.

How to write a communications plan for a project

Start from what each audience has to decide, not from what you would like to tell them. A communications plan is a routing table for decisions: information reaches the people who act on it while they can still act.

1. List the audiences, then collapse them. Sponsor, steering group, delivery team, affected users, suppliers. Five groups is usually enough. Fifteen rows means you will maintain none of them.
2. Write down the decision each group makes. The sponsor decides on budget and scope. Affected users decide nothing but need warning before their working day changes. If a group decides nothing and needs no warning, take them off.
3. Pick one default channel per group. Email where you need a record, chat for the day to day, a meeting only where discussion changes the outcome. Naming the default stops the same update being retyped in four places.
4. Set frequency against decision points, not the calendar. A steering group that meets monthly does not need a weekly pack. It needs a monthly pack and a phone call the day a date moves.
5. Fix the shape of the report now. Agree the sections and length before the first send. A report invented weekly grows into an essay by week six.
6. Name a person against every line, and a deputy. Roles do not send emails. “Comms lead” is not somebody you can chase on a Friday afternoon.
7. Write the escalation rule. State what counts as bad news, who hears it, and how fast: a milestone at risk, a budget variance over an agreed figure, a dependency blocked a week. Without that line, bad news travels at the speed of whoever is bravest.

Do this in one sitting with the people named on it. The line most often disputed later is the one where somebody was made an owner while they were on holiday.

What should a project communications plan include?

For every audience: the information they need, the channel, the frequency, the format, a named owner and the escalation route. Most templates arrange optional extras around those six.

Field	What good looks like	What it prevents
Information need	The decision or action it supports	Reporting because it is Tuesday
Channel	One default per audience	The same news retyped in four places
Frequency	Tied to when the audience decides something	Weekly packs nobody opens
Owner	A person, plus a deputy	The update stopping when someone is off sick
Escalation	Trigger, recipient, time limit	The sponsor hearing about a slip from the client
Review date	When the plan itself gets revisited	A kickoff artefact nobody has opened since

Keep it to one page. Two fields carry it: the information need, which stops you sending things nobody uses, and the escalation rule, the only part that matters on the day it goes wrong.

The plan gets weak in the same place every time: one person drafts it after kickoff, and the owners listed on it never agreed to their own line. Settle that column as a conversation. In Projan it runs as a Slack or Microsoft Teams thread where the group is asked who hears first when a date moves and who approves anything leaving the team, and the answers come out as the plan rather than somebody’s notes.

How to write a weekly status report

Write it in one pass against a fixed template: status against plan, what changed since last week, what is blocked, what you need and from whom, and what happens next. Twenty minutes, one screen. The sections themselves are covered in what a status report should include and in how to write a status report stakeholders actually read. What follows is the routine that keeps it arriving.

1. Book the slot. Same day, same hour, a recurring calendar entry with your name on it. Write on Friday while you still remember the week, send on Monday when people read.
2. Write from the record, not from memory. Open the plan, the risk log and the board first. Memory reports the loud problems and forgets the slow ones.
3. Keep the shape identical each week, and lead with what changed. Readers learn where the bad news lives and go straight to it. Nobody rereads the parts that are the same as last week.
4. Make asks specific. “Decision needed on the hosting contract from Anna by Thursday” beats “awaiting decisions”, which has never caused anyone to do anything.
5. Send it before the meeting, not after. The written update sets the agenda and the meeting handles the two lines people disagree with. That is also how you shorten the meeting, or stop holding it at all.

If the weekly report is the only part of the plan that survives, the project is still better off. It is also the first thing dropped, because it carries a deadline every week.

Why reporting cadences stop working by week three

They stop because the frequency was chosen at kickoff, when everyone was optimistic and nobody had yet had a delivery week from hell. Three things go wrong, usually in this order.

The cadence was set too high. Weekly for the delivery team is fine. Weekly for a sponsor who reads one line of it is a tax you pay for eleven months. Set the cadence you can hold in the worst week of the project, not the first.

Nobody owns the send. A habit dies when the person holding it goes on leave. Put the send in the tracker as a recurring task with an owner and a deputy, and it survives holidays and handovers.

The report is not used. If a report has never once changed a decision, it is not a report, it is a receipt. Ask the sponsor which line they read first. If the answer is vague, halve it and see who complains.

Keeping the plan current is the other half of the job. Revisit it at phase boundaries and whenever the stakeholder list changes: a new sponsor, a new supplier, the first real users on the system. Each is a new row or a changed frequency. Put the review date in the plan so it is somebody’s job rather than an act of conscience, and retire lines that have stopped earning their place.

Frequently asked questions

Who owns the project communications plan? The project manager or delivery lead owns the plan and the routine that keeps it running. The sponsor owns the escalation route, because escalation ends with them. Individual lines can sit with whoever is closest to that audience, such as an account lead for a client group, provided their name is on the line and they know it.

What is the difference between a communications plan and a stakeholder engagement plan? A communications plan covers information flow: who is told what, how often, through which channel, by whom. A stakeholder engagement plan covers relationships: who holds influence, what they currently think, and how you intend to shift that. On small projects the two collapse into one document. On anything politically awkward, keep the engagement thinking separate and unpublished.

Does a small project need a communications plan? Yes, though five lines will do it. One row per audience with a channel, a frequency and a name is a working plan. The cost of skipping it is the fortnight where two people each assume the other has been updating the client, and neither of them has.

A communications plan is worth writing only if it survives a bad month. Keep it to a page, name people rather than roles, and let the weekly update be the thing you protect when everything else slips.