A communication plan is a short written document that records who needs information about a project, what information they need, how often they get it, through which channel, and who is accountable for sending it. In practice it is usually one table, often called a communication matrix, plus a page of rules covering escalation, meeting cadence, and where documents live. Its whole job is to make sure nobody on a project has to guess who to tell.
That sounds trivial until you watch a project without one. The sponsor finds out about a slipped date from a supplier rather than the project manager. The finance business partner gets a weekly report they never read while the operations lead who actually needs it gets nothing. Two people both assume the other is briefing the steering committee. None of that is a communication failure in the soft-skills sense. It is a missing table.
Key takeaways
- The plan is the rules. The matrix is the table that does the work. Most people mean the matrix when they say plan.
- Every row needs a named owner. "The project team" is not an owner and guarantees the row will be skipped.
- Set frequency to the audience's decision cycle, not to the calendar. A weekly report to a monthly decision maker is waste.
- Write the escalation triggers before you need them. Agreeing what counts as bad news during the bad news is too late.
- At portfolio level, publish ONE standard plan and let projects document only their exceptions. Six pages of boilerplate per project is how the artifact dies.
What is a communication plan?
A communication plan is the document that defines how information moves on a project: which audiences exist, what each one receives, when, in what format, and from whom. It answers the five questions people actually argue about, which are who, what, when, where and why, and it turns them into a table that can be checked rather than a shared intention that cannot.
The term is used loosely, and that causes real confusion in practice. Some organizations call the whole thing a communication plan. Others call it a communications management plan, which is the phrase you find in formal project management method guides, and treat it as a subsidiary plan of the overall project plan. A third group calls the table a communication matrix and reserves the word plan for the narrative around it. All three describe the same artifact family. If someone asks you for one, ask which of the three they mean before you start writing, because the effort differs by a factor of five.
What matters more than the label is scope. A communication plan covers routine, planned information flow. It does not cover the ad hoc conversation, the corridor question, or the crisis. It also is not a stakeholder analysis, though it consumes one. If you have not already worked out who cares about this project and how much power they hold, the plan you write will be a list of email addresses rather than a piece of governance.
Communication plan template, section by section
A usable plan runs to about two pages. Longer than that and it becomes a document written for an audit rather than for the people who have to follow it. Here is what each section holds and the mistake that most often ruins it.
| Section | What goes in it | The common mistake |
|---|---|---|
| Purpose and scope | Two or three sentences: which project this covers, which phase, and what is deliberately out of scope (for example, external press handling). | Writing a paragraph of generic prose about the value of good communication. Delete it. |
| Audiences | The groups who need information, each with the decision or action they are responsible for. Groups, not individual names, except for the sponsor. | Listing 30 individuals. The list becomes unmaintainable the first time someone changes role. |
| Communication matrix | The core table: audience, what they receive, channel, frequency, owner, format. This is the section people actually use. | Filling it from a template without asking any audience what they need. |
| Meeting cadence | The standing meetings, their purpose, who chairs, who must attend, and what each one is allowed to decide. | Listing meetings without stating what each one decides, which is how you end up with four meetings that all review the same slide. |
| Escalation rules | The triggers that force information upward, who receives it, and within what time. Thresholds, not adjectives. | Writing "significant issues will be escalated promptly", which means nothing and will be interpreted differently by everyone. |
| Document location and access | Where the plan, reports, decisions and registers live, and who can read or edit each. | Assuming everyone has access. Somebody always does not, and they will not tell you for a month. |
| Review point | When the plan gets revisited, typically at each stage gate or when the sponsor or scope changes. | Omitting it, which is why so many plans describe a project that no longer exists. |
Swipe to see more →
Notice what is not on that list. There is no communication objectives section, no key messages section, and no success metrics section. Those belong to a marketing or corporate communications plan, which is a genuinely different document with a different purpose. Importing them into a delivery plan is the single fastest way to make it too long to use.
The communication matrix: the table that does the actual work
If you only build one thing, build this. The matrix converts good intentions into a checkable grid, and it is the part people return to during the project rather than at the start of it.
| Column | What it captures | Test for a good entry |
|---|---|---|
| Audience | The group receiving the information. | Can you name the decision this group makes? If not, they may not need a row. |
| Information | What they actually receive, named specifically. | "Progress update" fails. "One page status with RAG, milestone variance and open decisions" passes. |
| Purpose | What the audience is meant to do with it: decide, act, or simply be aware. | If the answer is "be aware" for every row, the plan is a newsletter. |
| Channel | Email, standing meeting, dashboard, chat channel, formal pack. | Is it a channel this audience already reads? A new channel nobody has adopted is a broadcast into silence. |
| Frequency | Daily, weekly, fortnightly, monthly, or at a named event such as a gate. | Does it match how often this audience can actually act? See the section on cadence below. |
| Owner | The named person who prepares and sends it. | A person, never a team. If it is a team, nobody owns it. |
| Format and length | One page, dashboard view, ten slide pack, verbal. | Has anyone agreed this length, or did the first author set it by accident and everyone inherit it? |
Swipe to see more →
The purpose column is the one most templates omit and the one that improves plans the most. Force yourself to write decide, act, or aware against every row. A matrix where nine rows out of ten say aware is telling you something uncomfortable and true: you are producing a lot of paper that changes nothing. Cut those rows to a single shared dashboard and spend the recovered hours on the rows where somebody has to make a call.
Communication plan example: a filled matrix for a live project
Abstract templates are easy to agree with and hard to copy. Here is the matrix filled in for a realistic case: a finance system replacement at a mid-size US business, roughly nine months, an external implementation partner, and three affected departments.
| Audience | Information | Purpose | Channel | Frequency | Owner |
|---|---|---|---|---|---|
| Delivery team | Blockers, today's priorities, dependencies due | Act | Standup, 15 min | Daily | Project manager |
| Implementation partner | Open action log, environment status, data questions | Act | Working session | Twice weekly | Technical lead |
| Project sponsor | One page status, RAG rating, decisions needed from her | Decide | Email plus 30 min call | Weekly | Project manager |
| PMO | Standard status fields, milestone variance, risk and issue movement, resource actuals | Aware plus rollup | Portfolio reporting template | Weekly, Thursday noon | Project manager |
| Finance team (affected users) | What changes for them and when, training dates, what to do about month end | Act | Team meeting plus written summary | Fortnightly, rising to weekly at cutover | Business change lead |
| AP and procurement leads | Process changes affecting invoice approval and purchase orders | Act | Working group | Monthly, weekly from user testing | Business change lead |
| Steering committee | Exception report, forecast to complete, decisions with options and a recommendation | Decide | Formal pack, issued 3 working days ahead | Monthly | Project manager |
| Executive leadership | Portfolio view: this project as one line, with confidence rating | Aware | Portfolio dashboard | Monthly | PMO |
| Whole company | What is changing, when, and where to ask questions | Aware | Intranet post plus manager cascade | At three milestones only | Business change lead |
Swipe to see more →
Three things in that example are deliberate and worth stealing. First, the sponsor row says decisions needed from her, not status update, because a weekly sponsor conversation with no decision in it will be the first meeting cancelled. Second, two rows change frequency at a named point rather than running at one rate for nine months, since the information need genuinely rises near cutover. Third, the whole-company row fires three times, not monthly. Broadcasting to people with nothing to do about it trains them to ignore you, and you will need their attention at go-live.
Notice also that the PMO row and the steering committee row carry different content drawn from the same underlying facts. That is not duplication, it is altitude, and getting it right is most of the work in a portfolio. The portfolio status report covers what belongs in the weekly version, and RAG status covers how to make the rating mean something consistent across projects.
How to write a communication plan in six steps
This takes about ninety minutes for a normal project if you do it in this order. It takes a week if you start with a template and try to fill the boxes.
- List audiences, not people. Group by the decision they make or the work they have to change. Individuals move roles; the finance function still needs to know when month end changes.
- Ask each audience what they actually need. Four questions each, and you can do most of them in a corridor: what do you need to know, how often, in what form, and what would you do differently if you knew it sooner. The last question is the useful one.
- Match an artifact to each audience. Resist inventing a new report per row. Most audiences can be served by one of three or four existing artifacts at different levels of detail.
- Set frequency from the decision cycle. Covered in the next section, and it is where most plans go wrong.
- Name one owner per row. Then check the total load on that person. If the project manager owns nine rows, the plan will silently degrade to whichever two the sponsor chases.
- Agree escalation triggers with the sponsor, in writing, before you need them. Numbers, not adjectives. Then get the plan confirmed at the project kickoff meeting, which is the only moment when every audience is in one room and can object.
Step two is the step people skip, and skipping it is why so many communication plans read as though they were written about a project rather than for one. It takes an afternoon. The alternative is discovering in month five that the operations director has been forwarding your weekly report to somebody else unread because it does not contain the one number she needs.
Choosing frequency: the cadence that survives month three
The rule that fixes most plans is short: set frequency to match how quickly the audience can act, not how often you can produce a document. Information arriving faster than a person can use it is not service, it is noise, and noise gets filtered. Information arriving slower than they need it means they will build their own shadow reporting, which is worse than no plan at all because now there are two versions of the truth.
| Tier | Audience | Question they are answering | Natural frequency | Artifact |
|---|---|---|---|---|
| 1 | Delivery team | What is blocking us today? | Daily | Standup |
| 2 | Project manager and leads | Are we still on the plan this week? | Weekly | Working review, updated registers |
| 3 | Sponsor | What decision do you need from me? | Weekly | One page status plus a short call |
| 4 | PMO | Is anything moving that changes the portfolio picture? | Weekly, same day and time for every project | Standard reporting template |
| 5 | Steering committee | Should this project continue as scoped and funded? | Monthly | Exception pack with recommendations |
| 6 | Portfolio board or executive | Is the portfolio still the right set of investments? | Monthly or quarterly | Portfolio dashboard, one line per project |
Swipe to see more →
The tier four row is the one PMOs get wrong most expensively. If every project reports on a different day in a different format, the PMO spends its week reformatting rather than analyzing, and the portfolio view is always stale by the time it is assembled. Fixing the day and the fields costs a project manager nothing and gives the PMO back most of a working week. The portfolio review meeting only works if the inputs arrived in a common shape.
Escalation belongs in the communication plan, with numbers
Escalation is communication under time pressure, which is exactly when informal arrangements collapse. Put the triggers in the plan and express them as thresholds a person can check without judgment.
| Trigger | Who is told | Within | Channel |
|---|---|---|---|
| Milestone forecast slips beyond the agreed tolerance | Sponsor | 1 working day | Call, then written confirmation |
| Forecast cost exceeds the approved budget tolerance | Sponsor and PMO | 1 working day | Written, with options |
| A risk rated high on both likelihood and impact is opened | Sponsor | Next weekly report at the latest | Status report, flagged |
| A dependency owned by another project misses its date | PMO and the other project manager | 2 working days | Written, copied to both sponsors |
| A change request exceeds the project manager's delegated authority | Change authority or steering committee | Next scheduled forum, or sooner if it blocks work | Formal change request |
| A safety, legal, or regulatory issue of any size | Sponsor and the relevant function | Immediately | Whatever is fastest, then written |
Swipe to see more →
Two of those rows do more work than the rest. The dependency row is the one that keeps cross-project failures from being discovered late by the PMO, and the delegated authority row is what stops quiet scope growth, which is the mechanism scope creep uses most often. The thresholds themselves should be inherited from the change control process rather than invented per project, so that the same slip means the same thing everywhere.
Communication plan, matrix, stakeholder register and RACI
These four artifacts overlap enough to cause arguments and differ enough that merging them produces something useless. The distinction is cleanest when you ask which question each one answers.
| Artifact | The question it answers | Typical owner | Changes how often |
|---|---|---|---|
| Communication plan | How does information move on this project, and under what rules? | Project manager | At gates or on major change |
| Communication matrix | Who gets what, how often, from whom? | Project manager | Whenever an audience or owner changes |
| Stakeholder register or analysis | Who cares about this project, how much power do they hold, and what is their attitude? | Project manager, often with the sponsor | Continuously in early phases |
| RACI matrix | Who is accountable for doing the WORK, and who must be consulted or informed? | Project manager | At phase boundaries |
Swipe to see more →
The practical seam between the last two is worth stating plainly because it causes real duplication. A RACI matrix assigns accountability for deliverables and decisions. The communication matrix assigns accountability for information. The I in RACI, informed, is the point where they touch: everyone marked informed on a deliverable should be findable somewhere in the communication matrix, otherwise you have promised to tell someone something with no mechanism to do it. Building both from the same list of audiences takes ten minutes and prevents the mismatch.
The PMO version: one standard plan across a portfolio
Everything above is the single-project answer, which is what almost every guide on this topic stops at. It stops being sufficient the moment you run more than about eight projects at once, because you are no longer designing communication for one project. You are designing it for a system in which twenty project managers each independently invent a reporting rhythm.
The move that works is inversion. Instead of every project writing a communication plan from scratch, the PMO publishes ONE standard plan covering everything that should be identical across the portfolio, and each project writes only its exceptions. The standard covers the tier four and above rows: what the PMO receives, on what day, in which fields, what the RAG definitions mean, when the steering pack is issued, and what triggers escalation. The project-level document then reduces to about one page, covering the audiences that genuinely are unique to that project, which are usually the affected business functions and any external parties.
The gains are not subtle. Reports arrive comparable, so the portfolio view can be assembled rather than reconciled. New project managers inherit a working cadence on day one instead of copying whichever old plan they can find. And when the PMO wants to change something, such as adding a resource-actuals field, it changes one document rather than chasing twenty. This is one of the more visible pieces of value a PMO function delivers, and it belongs in the project governance framework alongside the decision rights and the gate criteria.
There is a portfolio metric hiding in here that very few PMOs track and that is worth more than most of the ones they do track. Call it report to decision lag: the time between an issue first appearing in a project report and a decision being taken about it. If your reporting is working, that number is short and roughly constant. If it is drifting upward, information is arriving at forums that cannot act on it, and the fix is almost always in the matrix, either the wrong audience, the wrong frequency, or an escalation trigger that nobody agreed to. It is a far better diagnostic than counting how many reports were submitted on time, which measures compliance rather than usefulness.
A related check is cheaper still. Once a quarter, take the last four steering packs and ask how many decisions each one produced. A forum receiving a monthly pack and producing no decisions for a quarter is not a governance body, it is an audience, and it should be moved to the portfolio dashboard and given its hour back.
Why communication plans get written and then ignored
Five failure modes account for nearly all of them, and each has a specific fix.
It was written for the process, not the audience. The tell is a plan that exists as a completed template with no evidence anyone was asked what they need. It will be technically compliant and functionally dead. The fix is step two above, and it costs an afternoon.
The owner column says a team. Rows owned by the project team or the workstream are the rows that stop happening in week six. Everything needs one name, and if that name has too many rows, the plan is telling you the project is under-resourced for its own governance.
Frequency was copied rather than chosen. Weekly is the default because it is the default, not because the audience acts weekly. Half the plans I see could drop two rows to monthly and add a genuine escalation route, and everyone would be better informed.
It duplicates the dashboard. If an audience can already see the information whenever they want, sending it to them on a schedule is not communication, it is friction. Point them at the source and keep the scheduled artifact for things that need interpretation, such as a recommendation or an exception.
Nobody revised it after the project changed. A plan written at initiation for a project that has since changed sponsor, scope, and phase is worse than none, because people trust it. Tie the review to the stage gate process so it is revisited at points that already exist rather than relying on someone to remember.
There is a sixth failure that is really a governance problem wearing a communication costume. Sometimes the plan is fine and the information still does not move, because the person who has the bad news reports to the person who does not want to hear it. No table fixes that. It is handled by the project sponsor creating genuine safety around early warning, and by the PMO having a route to the steering committee that does not depend solely on the project manager's willingness to volunteer it. If you write only one thing into the plan that is unusual, write that route down.
Frequently asked questions
What should a communication plan include?
Seven sections: purpose and scope, the audiences, the communication matrix, meeting cadence, escalation rules with numeric triggers, where documents live and who can access them, and when the plan gets reviewed. The matrix is the part people use, and it needs audience, information, purpose, channel, frequency, owner and format.
What are the 5 W's of a communication plan?
Who needs the information, what they need, when they need it, where it will be delivered, and why it matters to them. Many practitioners add how, covering format and level of detail. The five questions map directly onto columns of the communication matrix, which is why the matrix is a better starting point than a blank page.
What is the difference between a communication plan and a communication matrix?
The plan is the whole document including the rules, scope, escalation triggers and review points. The matrix is the table inside it that lists audience, information, channel, frequency and owner. The plan explains why and under what rules; the matrix answers who gets what, when, and from whom. Most people asking for a plan want the matrix.
Who is responsible for the project communication plan?
The project manager owns and maintains it, and the sponsor approves it, mainly because the sponsor owns the escalation thresholds. Individual rows are owned by whoever prepares that communication, which is often a business change lead or technical lead rather than the project manager. At portfolio level the PMO owns the standard that projects inherit.
How often should a communication plan be updated?
Review it at every stage gate, and immediately whenever the sponsor changes, the scope changes materially, or a new audience appears. In steady delivery that usually means every two to three months. A plan more than a phase out of date should be treated as unreliable, because people will follow it and reach the wrong person.
What is a communication management plan?
It is the same artifact under the name used by formal project management methods, where it sits as a subsidiary plan within the overall project management plan. Expect slightly more formality, such as an explicit statement of communication constraints and assumptions, but the working content is the audiences, the matrix, and the escalation rules.
How do you write a stakeholder communication plan?
Start from the stakeholder analysis rather than the template. Group stakeholders by the decision or action each one owns, ask each group what they need and how often, assign one artifact and one named owner per group, then set frequency to their decision cycle. The output is a communication matrix filtered to external and business stakeholders rather than the delivery team.
What is an example of a communication plan?
A filled matrix for a nine month finance system replacement is shown above: daily standups for the delivery team, a weekly one page status and call for the sponsor, a standard weekly template to the PMO every Thursday, fortnightly updates for affected users rising to weekly at cutover, a monthly exception pack for the steering committee, and company-wide messages at three milestones only.
How long should a project communication plan be?
Two pages for a single project, of which the matrix is most of one. If a project inherits a PMO standard plan, its own document should be about one page covering exceptions only. Anything running past four pages is being written for an audit rather than for the people expected to follow it, and it will not be opened again.
What is the difference between a communication plan and a RACI matrix?
A RACI matrix assigns accountability for doing work and making decisions. A communication plan assigns accountability for moving information. They meet at the I, informed: anyone marked informed in RACI should appear somewhere in the communication matrix, otherwise you have committed to telling them something with no mechanism for doing it.
One last thing, and it is the observation that changes how these documents get written. The best communication plans I have seen are noticeably shorter than the worst ones. They are short because somebody did the hard work of deciding which audiences genuinely need something, rather than the easy work of adding a row for everyone who might one day complain about being left out. A plan with nine rows that all happen beats a plan with thirty rows of which eleven happen, and the second one is much easier to write. That is the whole trade, and it is worth making deliberately rather than by accident. If you need a place to record the decisions that come out of all this reporting, the RAID log is where they belong.
Last updated August 2026.