How to Improve Project Communication: End the “Nobody Told Me” Problem

Why it matters, and what the data can and cannot say

The Project Management Institute (PMI) published a 2013 Pulse of the Profession piece, The Essential Role of Communications. It reports that 56 percent of dollars spent on projects are at risk due to ineffective communications, and that highly effective communicators were more than five times as likely to be high-performing organizations as minimally effective ones (38 percent versus 7 percent).

Treat those numbers carefully. They come from a survey more than a decade old, the page does not describe the sample, and survey results show association, not proof of cause. What they do support is a simple point that most project managers already feel: unclear communication is expensive, and it is a common reason projects drift.

This page is about the system behind communication. For the words themselves, such as how to phrase an update or a hard request, see soft skills for project managers. For ready-made status, risk-log and agenda templates, use our project management tips.

The channel math

Every pair of people on a project is a possible communication channel. A 2010 PMI research paper cites the PMBOK Guide (4th edition) for a formula that counts them: with N people, the number of channels is N(N−1)/2.

Our own reading of the table: a six-person team has 15 channels, but add eight stakeholders and it jumps to 91. Nobody can keep that many conversations in sync by memory. That is why informal communication that works for a small team stops working as a project grows, and why a short written plan becomes useful.

Find where yours breaks

Before adding meetings or tools, name the symptom. Most communication problems fall into a handful of patterns.

Run a quick check: ask five people on the project to name the top three risks and the next milestone date. If the answers differ, you have found the gap.

The one-page communication plan

A communication plan is a table that answers, for each recurring message: who needs it, what it says, how it is sent, who sends it and how often. One page is enough for most projects. Add a row only when a real audience needs a real message.

Our made-up example. A six-person team is relaunching a company website over ten weeks. This is an illustration, not a real project.

Notice what the plan avoids: it does not send the full status report to everyone. Each group gets what it needs and nothing more. If you need a starting point for the status format itself, copy the template in our tips guide.

Build yours in four steps.

1. List everyone who gives input, makes decisions or is affected.
2. Group them by what they need to know, not by job title.
3. Choose the lightest channel and the lowest frequency that still works.
4. Name one owner for each row, then share the plan and ask for corrections.

Review the plan whenever the project changes phase or a new group joins. Our guide to project team roles and responsibilities helps with the audience list.

Pick the channel for each message

Teams run into trouble when every message goes through one channel, usually chat or email. A simple rule set removes the guessing.

Write the rules in two or three lines at the top of your plan. For example: “Decisions go in the log. Urgent items get a call. Chat is for quick questions only.”

A meeting rhythm that does not eat the week

A rhythm replaces many ad hoc meetings with a few predictable ones. This is one workable pattern, not a rule.

• Daily check-in (15 minutes, core team). Each person says what they will finish, what is blocking them and who they need. Take long discussions offline.
• Weekly status (30 minutes or a written update). Progress against the plan, risks and decisions needed. Send it the same day each week.
• Monthly steering or sponsor review. Big decisions, budget and direction.
• Phase-end review. What worked, what to change. See our guide to the five phases for where these fall.

Every meeting should have a goal, a decider and a next action for each point. If a meeting has none of these, cancel it or replace it with a written update.

Bad news and escalation

Most “surprises” are problems that were known earlier and not reported. Agree on an escalation rule in advance, so people know when to speak up and to whom.

When you bring a problem, bring the facts, the options and your recommendation. A message such as “Testing is three days late because the environment was down; we can extend by three days or drop one feature; I recommend dropping the feature” invites a decision. A bare “we have a problem” invites worry. For why project managers need to be willing to decide, see project manager decisiveness.

Remote and async teams

When people work in different places or time zones, things that happen by accident in an office need to be set up on purpose.

• Write more down. A decision made on a call does not exist for people who were not there until someone posts it.
• Agree overlap hours. Pick a window when everyone is reachable, and keep meetings inside it.
• Set response expectations. For example: chat within a few hours, email within one working day, urgent items by phone.
• Make status visible. A shared board or page lets people check progress without asking.
• Rotate meeting times. If one group always meets at an awkward hour, move it around.

A 30-day rollout

If the answers in week 4 match each other better than in week 1, the system is working. If not, look at the audience and owner columns first.

Common mistakes

• Copying everyone on everything. It feels safe and trains people to ignore you.
• Relying on chat for decisions. Threads are hard to search months later.
• Holding bad news until you have the solution. Report early, even if you only have options.
• Skipping the audience. A plan that lists tools but not people will fail.
• Writing a plan and never using it. Revisit it whenever the project shifts.
• Confusing talking with communicating. Communication is complete only when the other person understood and can act.

Learn more

If you want structured practice, online providers such as Coursera and Udemy list project management courses, some with modules on communication and stakeholder management. We may earn a commission if you sign up, at no cost to you. We are not affiliated with any university. Check the syllabus before you pay. For related reading, see our guide to the top project management challenges and the PMBOK planning process group.

Frequently asked questions

How do I improve communication on a project?

Find where it breaks, write a one-page plan with audience, message, channel, owner and frequency, set channel rules and a meeting rhythm, and agree when to escalate. Then check after a month whether people’s answers line up.

What is a project communication plan?

A short document that states who needs which information, in what form, through which channel, from whom and how often. It replaces guesswork with a shared routine.

What goes in a communication plan?

At minimum: audiences, what each needs, the channel, an owner and a frequency. Many plans also add escalation rules and where documents are stored.

What is the communication channel formula in project management?

N(N−1)/2, where N is the number of people. It shows how fast possible channels grow: 5 people have 10, 10 people have 45. The formula is cited from the PMBOK Guide.

How often should a project manager send status updates?

Weekly suits many projects. Fast-moving or high-risk work may need more, and long, steady projects may need less. Ask your sponsor what rhythm they want and keep to it.

How do I communicate bad news on a project?

Tell the right person early, by call if it is serious, with the facts, the options and your recommendation. Follow up in writing so the decision is recorded.

How do I reduce meetings without losing alignment?

Give every meeting a goal and a decider, replace status meetings with a written update where you can, and keep a decision log so people do not need to ask.

Which tools help with project communication?

Chat for quick questions, a shared board for status, a document home for files and a log for decisions. The tool matters less than the agreed rules for using it.