There is a quick test for whether a project has a communication plan. Ask three people on the project where it is. If two say it is in the project folder somewhere and the third asks what it covers, what the project has is a document that passed an approval gate.
Plans get abandoned for predictable reasons, and none of them is that communication stopped mattering. They get abandoned because the plan was written to satisfy a gate, in a format nobody reads, listing activities nobody owns, with no event that ever causes anybody to open it again.
Length is the first problem. A communication plan running to eleven pages with a twenty-two row matrix exists to satisfy a checklist. Nobody consults a twenty-two row matrix on a Wednesday afternoon. The version people use fits on one side and names about six things.
Ownership is the second. A plan in which every row says the project manager will communicate has one bottleneck and no redundancy. Rows naming somebody other than the project manager, who has agreed to it, are the rows that survive a busy fortnight.
The third is that nothing triggers a review. A plan written during mobilisation and never reopened describes a project that stopped existing around month four. The cheap fix is to hang the review on something that already happens: a phase boundary, a quarterly planning session, the arrival of a new sponsor.
The fourth is format. A plan describing channels the audience does not use is a plan for a different audience. Any row that says email, addressed to people who do not have a desk, is decorative.
Section 2.5 of the PMBOK® Guide Eighth Edition keeps communication inside the stakeholder work rather than treating it as a separate administrative track, and the tailoring material in the domain is the part most worth using. Three axes carry nearly all of it.
Formality follows consequence. A communication that creates or varies an obligation, a contractual notice, a regulatory submission, an acceptance of change, needs a record, a date and a named sender, and the formality is doing real work. A communication whose whole job is to keep a team informed needs none of that, and wrapping it in the same apparatus makes it slower without making it better. Most projects apply one level of formality to everything, usually whichever level their template arrived with.
Cadence follows the delivery rhythm. In predictive work the natural beats are stage boundaries, baseline changes and whatever reporting cycle the governance already runs. In adaptive work the iteration review is itself the communication, and a separate monthly update to the same people duplicates it and arrives later. Hybrid delivery needs both beats and usually gets whichever one the project manager is used to.
Format follows the audience's working life. This sounds obvious and is the most frequently broken of the three. People on shift, on site, in vans, on a ward or on a production floor do not read email during the working day and are not about to start. What reaches them is already in their day: the shift handover, the board at a point they walk past, the supervisor who briefs them, a message group they are already in. A plan built around the channels the project office finds convenient reaches the project office.
A facilities team was refurbishing three floors of an occupied office building, working floor by floor across eight months with the building in use throughout. The communication plan had been written properly: a weekly email bulletin to occupants, a monthly report to the landlord's representative, a project page on the intranet, a fortnightly contractor meeting.
Complaints ran at about fifteen a week for the first two months, and nearly all of them were about timing. A drilling day nobody expected. A lift out of service. A fire door propped open. A cleaning team unable to get into a space. The weekly bulletin had carried every one of those facts. The people complaining were cleaners, security staff, a catering contractor and the building's own engineers, and not one of them had a corporate email account or any reason to open an intranet page.
The replacement was cruder and worked. A printed look-ahead covering the next two days went up at the goods lift and both stair lobbies each morning, which cost one person ten minutes. The four supervisors whose teams were affected joined a message group with the site manager. The weekly bulletin carried on for the office occupants, because for them it was the right channel. Complaints dropped to two or three a week, and the plan lost four rows and gained two.
Nothing about the information changed. The same facts went out in the same week. What changed was that they arrived in front of people who could act on them, in a form those people met without having to go looking for it.
For a PMP® candidate, checking what a described channel actually reaches has to come before any judgement about whether the communication was adequate. A project manager who has published everything, with a group of people still surprised, is facing a channel problem or a translation problem, and the fitting response changes the route rather than the volume. The question to put to any communication in a situation is whether the person who needed it would have met it in the course of their day. A structured PMP exam preparation course is a good place to work through situations where the plan is faultless and the outcome is not.
Take the plan and a highlighter, and mark every row where the channel is one the recipient already uses without being asked to. Rows that fail the test go back to be rewritten around something that is in that person's day anyway. A plan that comes out of the exercise with six rows and no matrix is better than the one that went in, and somebody will open it again in March.
A communication plan that satisfies a governance checklist and reaches nobody is a common and expensive combination. Omega's PMP® Exam Preparation works through situations where the information went out correctly and the outcome still went wrong.
The Stakeholders Performance Domain, which is where the communication work sits, is set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
A132: The PMBOK 8 Stakeholders Performance Domain: What It Really Covers
A136: Why Hostile Stakeholders Still Need Engagement
A137: When Stakeholders Disagree: What Should the PM Do First?
A134: Power/Interest Grid vs Salience Model
A152: The PMBOK 8 Risk Performance Domain: What It Really Covers
PMP and PMBOK are registered marks of the Project Management Institute, Inc.