PMBOK® Guide 7th Edition alignment: Principles “Effectively engage with stakeholders,” “Create a collaborative project team environment,” and “Tailor based on context.” Performance domains: Stakeholders, Planning, and Team.

In brief: For PMs and team leads who run recurring meetings and status updates. This post shows how to plan communication the way PMBOK 7 frames it, with evidence from three peer-reviewed studies.

A ten-minute question cost me two weeks.

I was a remote intern during quarantine and hit a technical snag I couldn’t solve alone. My colleagues were juggling several critical tasks, and I couldn’t walk over to their desks. So I waited for the next scheduled call, and the next. By the time I had an answer, a simple problem had become a recurring stand-up discussion. Nobody was careless. We just had no plan for how a stuck newcomer reaches a busy colleague.

If you hold stakeholder calls and keep hearing “but we already talked about this,” you know that feeling. The stakes are bigger than annoyance. Andersen et al. (2006) studied projects across the UK, France, Norway, and China and found that rich project communication was among the main contributors to project impact. It also helped teams capture experience. Bad communication doesn’t just slow today’s work. It stops your team from learning from it.

Connecting the Dots

Once I started noticing the pattern, I couldn’t stop seeing it. I’ve seen it in my personal life, too. When we sat down with our designer for our new house, we had no agenda and no agreed roles. We nodded along to suggestions, then disagreed afterward. Different setting, same root cause: nobody had planned how the conversation would work. And I never asked my colleagues when they were free, which is the internship version of the same mistake.

Bigbee (2019) surveyed 91 IT project professionals on 18 aspects of project communication. Respondents largely agreed on what mattered, but internal and external communication carried different importance for project success. My reading, which is an inference: one approach for every audience will miss.

Step 1: Plan It (Planning Domain)

PMBOK 7 treats communication as part of planning, and it frames planning as continuous, not a one-time document (Project Management Institute, 2021). Secondary summaries of the guide list the questions to settle: who needs information, what they need and why, how often, through which channels, and who is responsible. Here’s a fill-in plan built on those questions:

Who needs it What and why How often Channel Owner Review date

Match the effort to the project. A small team needs a few rows. A complex one needs more.

Step 2: Choose the Method (Stakeholders Domain)

PMBOK distinguishes interactive, push, and pull communication. My application of those three:

  1. Does the audience need to respond, decide, or discuss? Yes: interactive (meeting or call).
  2. Is it reference material they can fetch on their own time? Yes: pull (shared site or repository).
  3. Otherwise: push (a short message to the people who need it).

Cardon and Marshall (2015) surveyed 227 business professionals and found that traditional channels were used more and rated more effective for team communication than social networking tools. It’s a 2015 survey, so treat it as a caution about defaulting to chat.

Step 3: Fit the Audience

Tailoring is the principle at work here. Different stakeholders need different information, so use the “What and why” column to write each row for the receiver. Picture a status call where the presenter walks a non-technical audience through every technical detail (a hypothetical, but you’ve likely sat through it). The main message gets buried. Writing the row for the receiver prevents that.

Step 4: Plan for Distance (Planning and Team Domains)

Remote work gave me three barriers: timing (limited availability), technology (dropped connections, power outages, platform bugs), and distance (no walking over to a desk). Secondary summaries of PMBOK 7 note that distributed teams need deliberate planning for connection, technology, and collaboration. So fill in the Channel and Owner columns before work starts, not after someone is stuck.

Step 5: Check and Adjust (Stakeholders Domain)

Ask stakeholders whether the frequency and depth of communication are working, then update the plan. I connected the dots here too. Once we started checking in with each other after each session with our designer, those meetings got noticeably better. On the Team side, I learned to say “I don’t know, would you mind explaining it?” instead of going quiet. That’s a personal habit, and it’s consistent with the Team domain’s emphasis on open communication.

Where This Breaks

Planning costs time, and too much planning is as ineffective as too little. Interactive communication is also the most expensive method, so reserve it for conversations that need it.

The Takeaway

Communication usually fails at fit, not volume. Plan it, pick the method, write it for the receiver, and review it.

Checklist (copy it):

If you’re heading into a status meeting soon, try filling in that table for just one project and putting a review date on the calendar. It’s a small step, and it’s enough to start. And here’s what I keep chewing on: when does a status meeting stop being worth the time compared with a pull-style dashboard? I’d honestly like to hear where you’d draw the line.

References