Plan and Manage Communication

You send the weekly status email to forty people, yet the sponsor still asks in the steering meeting why nobody flagged the vendor slipping. The information went out; it did not land, and that gap is what this page is about. About 90% of a project manager's time goes to communicating^[1], so the difference between a project that feels in control and one that feels chaotic is usually not the plan itself but how deliberately that communicating is done. Do that deliberately and you can define a communication strategy, pick the right method for each message, keep information visible, and confirm it was actually understood.

A communication strategy is the plan that answers, for each stakeholder, four questions: what information they need, in what format, through which channel, and how often. PMI frames managing communication as planning, designing, implementing, and then monitoring how you communicate with stakeholders^[2], which is the loop shown below: plan the strategy, choose a method for each message, share information openly, confirm it was understood, and adapt as feedback comes back. The strategy is never one broadcast for everyone, because a single format and cadence over-informs some readers and starves others.

The reason a strategy matters more as a project grows is arithmetic. The number of two-person channels among a team rises as N(N-1)/2, so a team of five already has ten channels and a team of ten has forty-five^[1]. Every added person multiplies the ways a message can be missed or garbled, so a larger group needs more deliberate structure, not just more email into the same inboxes.

Once the strategy says who needs what, each message still needs a delivery method, and PMI sorts these into three: interactive, push, and pull. Interactive communication is a two-way, real-time exchange such as a meeting, call, or video session, where people can question and confirm on the spot. Push communication is a specially constructed message sent directly to named recipients^[2], like a status email, memo, or report, and it fits when people must receive something but no discussion is needed. Pull communication makes a large volume of material available for stakeholders to take at their own discretion^[3] through a shared drive, wiki, dashboard, or project portal. The table at the top of the page sets the three side by side; the rule is to let purpose and urgency choose the method, not habit.

Richer channels for complex or sensitive topics

The same three methods also line up on a second axis, how rich the channel is, meaning how much tone, nuance, and immediate feedback it carries. Pull is the leanest, one-way material taken on demand; a push email is richer but still one-way, sent to named recipients; and interactive is richest of all, two-way and real-time, with a face-to-face conversation the richest form of interactive communication. The richness spectrum in the figure below is why difficult or conflict-laden news belongs in a live conversation: complex, sensitive, or contested topics need the read-on-tone and instant feedback that only an interactive channel gives, so delivering hard news by mass email, a lean push channel, reliably breeds confusion and offense. The mirror-image mistake is just as common, emailing everything, including matters that genuinely need real-time give-and-take, because email is convenient.

The cheapest way to keep people informed is to stop hiding the information in the first place. An information radiator is a highly visible display of project status, such as a task board or burndown chart posted where the team and stakeholders can see it at a glance, so progress and impediments are on show rather than locked in a report the project manager releases on request. Openly visible information builds trust and cuts the time everyone spends chasing updates, which is why transparency is one of the three pillars of Scrum^[4], alongside inspection and adaptation.

Lightweight collaboration beats reporting overhead

Frequent, lightweight collaboration does more for shared understanding than adding formal reports that consume effort without adding insight. When communication is failing, the instinct to commission another weekly report usually makes it worse; more conversation, not more paperwork, is the fix.

The daily standup is the team's event, not a status meeting for you

The daily standup carries a name that invites a predictable misread, so debunk it up front: it is not a status report the team delivers to the project manager. The Daily Scrum is a fifteen-minute event for the developers of the team^[4] to inspect progress toward the goal, plan the next day's work, and surface impediments. (The Daily Scrum is Scrum's name for it; short daily coordination meetings appear across agile approaches.) The team owns the event, and imposing it top-down as a status-collection meeting drains its value and breeds resistance.

A message is not finished when you hit send; it is finished when the receiver understands it. Because sending and understanding are different events, build feedback loops that confirm each important message was received and correctly interpreted, for example by asking the receiver to restate the decision in their own words, or by checking that a request actually produced the intended action. Assuming a sent message was understood is how a small misread grows quietly into rework discovered at a milestone.

The same feedback does double duty. Beyond confirming individual messages, watch how well the communication is working overall and use that signal to adjust the strategy as the project, the audience, and their needs change. A communications plan written once at kickoff and never revisited drifts out of step with its stakeholders, so treat the strategy as a living plan, re-tuned whenever feedback shows a channel or cadence is no longer landing.

Reporting and communicating are not the same thing^[2]: a report is a formal, structured, often standardized way of delivering data about the project and its progress, and producing one does not guarantee anyone understood it. Reporting is nonetheless a governance obligation, so establish who needs which report, at what cadence and level of detail, to satisfy the sponsor's and the organization's oversight requirements, and support the reporting and governance processes^[5] rather than inventing a private format. A report that ignores what governance actually requires fails audit and oversight no matter how polished it looks. This required governance reporting is not the reporting overhead to cut: the earlier point was against piling on extra reports as a substitute for real communication, not against the reporting that governance legitimately requires.

Shape each report to its reader

PMI's exam content outline names the task as creating reports aligned with sponsor and stakeholder expectations^[5], which in practice means tailoring content and depth to the audience. Executives and sponsors need outcomes, exceptions, and the decisions in front of them, presented concisely; the delivery team needs operational detail. Handing the sponsor the full detailed team report, or handing the team a one-line executive summary, buries the signal each audience needs under the other's noise.

PMP communication questions rarely ask for a definition. They drop you into a situation, usually one where information technically went out but did not achieve its purpose, and ask for the best next action. The tempting wrong answers are almost always the convenient channel or one more report.

What the stems look like, and the answer that wins

• A stakeholder complains they were not informed, though you did send updates. Right: confirm what they received and understood, and repair the feedback loop. Wrong: resend the same email, or note that the update was already distributed.
• You must deliver bad or sensitive news. Right: use an interactive channel, a call or a face-to-face conversation. Wrong: send a mass email or post a notice.
• A large reference document must reach a broad audience. Right: publish it as pull, in a shared portal or wiki. Wrong: attach it to an email blast to everyone.
• Communication is breaking down as the team grows. Right: re-plan the communication strategy for the larger set of channels. Wrong: add another status report.
• The team resists the daily standup, or leadership wants it run as status collection. Right: return it to the team as their own coordination event. Wrong: have the project manager run it to collect status.
• The sponsor wants project status. Right: give a concise, outcome-focused report at the cadence governance requires. Wrong: forward the full detailed team report.

The through-line

Two habits settle most of these. First, communicating is not the same as sending: the loop closes only when the message is understood. Second, method follows purpose: choose interactive, push, or pull from what the message needs, and reach for richer, more interactive channels as topics get more complex or sensitive, rather than defaulting to whatever is convenient.