Change · 10 min read
The Project Communication Plan People Actually Read
Most communication plans are tables nobody opens. A lighter plan built around audiences, moments and the channels people really use.

Here is a scene from almost every organization. A project manager sends a carefully written email announcing an important change. Two days later, in a meeting, someone asks a question that the email answered in the second paragraph. The manager feels frustrated: "I told everyone." Everyone feels uninformed: "Nobody told us anything." Both are right. The message was sent. It was not received.
This gap between sending and receiving is where many projects bleed time. Decisions are repeated, people work on outdated information, rumors fill silences and resistance grows from simple uncertainty. A communication plan is meant to prevent this, yet most plans are tables filled out once, saved in a folder and never opened again. In this article, I want to propose a lighter and more useful version: a plan built around the people you need to reach, the moments that matter and the channels they genuinely use. There is a short timeline tool in the middle that turns your key date into a schedule of messages.
Why most communication plans fail
Before building a better plan, it helps to see why the usual ones do not work.
They are long and generic. A twelve-column matrix lists every stakeholder, every message type and every channel, and takes more time to maintain than to ignore. So it is ignored.
They are written for the project, not the audience. They describe what the project wants to say, not what people need to hear. "Project update" is not a message. "From Monday, invoices must be entered in the new system. Here is a ten-minute video showing how" is.
They are one-way. Announcements go out, and nothing comes back. The team learns of confusion only when mistakes appear.
They are mistimed. Information arrives either far too early, when it is forgotten, or too late, when it can no longer influence anything. People who learn about a change on the day it happens feel ambushed.
And they are channel-blind. They assume everyone reads email, when half the team lives in chat, and the people on the shop floor see neither.
Start with audiences and actions
A useful plan begins with a short list of audiences, grouped by how they relate to the project. Your stakeholder map is the natural source. For each audience, answer three questions in a line or two.
- What do they need to know? The facts they require to do their part.
- What do you want them to feel? Confident, informed, respected, or at minimum not alarmed.
- What do you want them to do? The specific action: attend training, enter data, approve a document, simply stay calm.
The third question is the most important and the most often skipped. If a message does not lead to an action or a decision, ask whether it needs to be sent at all. Often, the answer is that you are communicating to feel covered rather than to help people act.
Six kinds of messages
Most project communication falls into six types, and each has its own rhythm and tone.
- Announce: tells people something is happening and why. Best delivered by a credible leader, ideally in person or on a call, with a short written follow-up.
- Explain: gives the detail: what changes for whom, when and how. Works well as a short written guide, a video or a briefing.
- Ask: requests a decision, an input or a task. Needs one clear ask, a date and a name.
- Update: shares progress. Short, regular and predictable, like a weekly one-page note.
- Celebrate: recognizes progress and people. Often forgotten and always valuable.
- Warn: shares bad news, a risk or a delay. Needs speed, facts and options.
Naming the type before writing the message clarifies the format. An "ask" buried inside an "update" is the most common reason requests are ignored. Separate them.
Pick channels people actually use
A simple idea helps with channel choice: the richer the channel, the better it handles sensitive or complex messages, and the poorer the channel, the further it reaches. At the rich end are one-to-one conversations. Then come small meetings, then video calls, then written messages, and finally broadcasts like posters or all-staff emails.
Match the message to the channel. A change that affects someone's job should reach them in a conversation before it appears in writing. A deadline reminder can be a chat message. A policy detail belongs in a document people can search. And a message that matters should travel through two or three channels, because people notice different things in different places. A common saying among communicators is to tell people three times in three ways. It sounds repetitive, and it works.
Ask people how they prefer to get information. In a restaurant or a construction crew, the best channel might be the pre-shift huddle. In a small office it might be chat. For executives it might be a short call. A plan that uses the channels people already live in will be read, and one that asks them to visit a new portal will not.

Plan the calendar backward
Communication works best when it is timed to the project, and the easiest way to time it is backward from a key date: a launch, an opening, a deadline or a handover. Work back from that date and place a few messages at the right moments. Too many messages create noise, and too few create silence.
A typical pattern for a change or launch looks like this. Several weeks before, leaders are briefed first so that they can answer questions. Then comes the announcement to everyone, with the reason and the timeline. Then the people most affected receive detailed explanations and invitations to training. A reminder with the answers to common questions follows. At the start, a clear go-live message goes out. After the launch, there are check-ins, a pulse survey and a celebration of what worked.
Enter your own key date in the tool below to see a sample schedule. It is a template for thinking, so adapt each step to your project.
Rules for good project messages
A few habits improve almost any message.
Put the bottom line first. The first two lines should tell the reader what this is and what they need to do. Many people read no further.
One message, one purpose. If you need an update, a decision and a thank-you, send three messages or clearly separate sections.
Use plain words. Avoid jargon and acronyms people have not been taught. If a ten-year-old could not follow the main point, simplify.
Be specific. Replace "soon" with a date. Replace "the team" with a name. Replace "some changes" with a list of the changes.
Write subject lines that work. "Action needed by Thursday: confirm your training slot" will be opened. "Project update" will wait.
Keep it short. If you need more than a screen, link to the detail and summarize the essentials.
Say it consistently. When several people communicate about a project, agree on the key messages beforehand so that the story does not drift.
Meetings that deserve to exist
Meetings are a communication channel, and a very expensive one. Treat each as a small product. A daily stand-up of ten minutes for a team working closely can save many longer meetings. A weekly review of thirty minutes with fixed agenda items, such as numbers, exceptions and decisions, keeps a project on rhythm, as I describe in data-driven project management. A monthly or phase-end review with the sponsor covers the bigger picture.
For any meeting, ask whether it needs to exist, who truly needs to be there and what decision or outcome it should produce. Publish a short agenda beforehand. Send notes with decisions and owners within a day, because the notes are what most of the organization will actually read. And cancel recurring meetings that have lost their purpose. People will thank you.
Make it two-way
A communication plan that only pushes information out is half a plan. People need ways to ask, challenge and warn you, and you need ways to hear the answer. Build in a few listening channels: a visible place for questions with answers published as an FAQ, office hours or short drop-in sessions, a way to ask anonymously for sensitive topics, regular conversations with your change champions and a brief pulse survey after major milestones.
And close the loop. When someone raises a concern, answer it visibly, even if the answer is "not now" or "no, and here is why." A team that sees its questions result in action will keep sending them. A team that sees silence will stop, and you will lose your early-warning system.

Handling bad news
Bad news is where communication plans are tested. The principles are simple, though not easy.
Be early. The day you learn something is the day to share it, even if you do not yet have all the answers. "We have found a problem, here is what we know, and I will update you by Friday" is far better than silence until you have a complete solution.
Be factual. State what happened, what the impact is and what is being done. Avoid blame, speculation and spin.
Bring options. Wherever possible, pair the problem with a proposed response or a choice for the decision-maker, as in keeping your executive sponsor engaged.
Use one voice. In a sensitive situation, agree on who speaks and what the key messages are, so that people do not receive conflicting information.
Follow up. Promise a next update and keep the promise. The silence after bad news is what damages trust the most.
Different projects, different communication
The mix of audiences and channels changes with the project. In the opening of a lodge or restaurant, such as Comtury Lodge or the kitchen routines behind your restaurant is a project, the audiences include staff, suppliers, local authorities and the first guests, and the pre-shift huddle is often the best channel for the team.
In public works, formal letters and records are part of the contract, communities may need notices in person and the paper trail matters, as I describe in contract risks that quietly cost projects.
In a startup, the audiences are small but critical: the team, early customers, advisors and investors. A short monthly update to investors, with numbers, wins, problems and asks, can be the most valuable communication a founder sends.
In a remote or international team, time zones matter, so written, asynchronous updates and recorded briefings become the backbone, with live calls reserved for discussion and decisions.
In a change or software rollout, communication is the engine of adoption, as I explain in change management and the people side of projects.
A worked example: a new scheduling tool in a restaurant
To see the pieces together, imagine a small restaurant group that is switching from a shared paper schedule to a scheduling app. This is an illustration, not a real case. The audiences are the kitchen team, the servers, the managers and the owner.
The owner first meets the managers for fifteen minutes to explain why: fewer last-minute shift swaps and no more phone calls on days off. Managers get the answers to the five questions they expect. Then, at the pre-shift huddle, the manager tells the whole team in plain words what changes, which day it starts and what they must do: install the app and set their availability by Friday. A one-page guide with screenshots is posted in the kitchen and sent by chat, because that is where the team actually reads.
Two champions, one from the kitchen and one from the floor, volunteer to help colleagues during the first week. On day one, a short message confirms the start. A week later, the manager asks two questions at the huddle: "What is confusing?" and "What is working?" Answers go into a small FAQ. After a month, the owner thanks the team and shares one number: last-minute swap requests fell. Each step was short, sent through a channel people use and designed around one action. That is the whole philosophy of a communication plan that gets read.
A one-page communication plan
Here is a format that fits on one page and that people actually use. Make a table with five columns: audience, what they need to do, message and type, channel, and owner with frequency. Fill in four to eight rows, only for the audiences that matter. Add a final row for "bad news protocol" naming who decides, who speaks and how quickly. Print it, post it where the team works and review it in your monthly governance check, as suggested in project governance for small teams.
How to know it is working
You do not need elaborate analytics. Try a few simple checks. Ask five people to explain, in their own words, what is changing and when, which is called a teach-back, and listen for gaps. Watch whether the same questions keep coming up, which means the message is not landing. Count responses to your asks within the time you requested. And run a two-question pulse: "Do you know what is expected of you this week?" and "Do you know where to go with a question?" If the answers are not mostly yes, adjust the plan.
Good communication does not mean more messages. It means the right message, to the right person, at the right time, through a channel they use, with a way to answer back. If you would like help designing communication for a launch, a change or a rollout, it is part of my scaling strategy service and the weekly rhythm of Project Focus.
What is the channel that actually works best in your team? Tell me in the comments.
Frequently asked questions
What should a project communication plan include?
For each key audience, what they need to know, feel and do; the message and its type; the channel; the owner; and the timing, plus a protocol for bad news. Keep it to one page and review it monthly.
How often should project updates be sent?
Weekly is a good default for most teams, in a short and predictable format, with more frequent touchpoints for people closely involved and less frequent ones, such as monthly, for distant stakeholders.
What is the best channel for project communication?
There is no single best channel. Use conversations for sensitive or complex topics, written messages for details people may need to search, and broadcasts for simple facts, and use the channels your audience already uses.
How should bad news be communicated?
Quickly, factually and with options, through one agreed voice, and with a promised follow-up. Early and imperfect honesty is better than late and complete explanations.
Join the conversation
Did this help? A quick reaction tells me what to write next.
Be the first to react.

Loading comments…