Manage Communications: Sending Information Is Not Communication
At two in the morning on a migration weekend, an application team ran a load that should not have run. The instruction that the database would be read-only from six o'clock had been understood as covering the user-facing services and not the overnight batch. It had been issued in writing, walked through in the cutover briefing, and acknowledged by the team lead. Every box in the communications plan was ticked, and the information had not arrived.
Managing communications is the work of closing that gap. Sending is an activity the project controls completely and can finish without anybody else being involved. Communication is a state at the far end: the person holds the information, understands what it means for them, and does something different because of it. The second one is what is worth reporting, and it is much harder to observe.
Three places a message dies
It fails to arrive. This is the dullest failure and the most common. The distribution list is stale, the person is on leave, it went to a shared mailbox nobody owns, the channel is one they never open. Arrival failures are cheap to find and cheap to repair, and they are seldom the expensive ones, because somebody usually notices the silence.
It arrives and is read differently. This is the two-in-the-morning failure. The sender has a context that makes the message unambiguous, and the receiver has a different context that makes it equally unambiguous in another direction. Project language is full of words that mean something precise inside the project and something else outside it: frozen, read-only, complete, signed off, in scope. A reader with operational duties maps those words onto their own world, and their mapping is the one that governs what happens on Saturday night.
It arrives, is understood, and nothing follows. This happens when a message contains no request. An update describing a change of approach, copied to twelve people, asks nothing of any of them, and eleven will reasonably conclude that nothing is needed from them. Where a communication requires somebody to act, the action has to be named, addressed to a person and given a date, or it has not been asked for.
Confirmation that costs less than the failure
Section 2.5.2 of the PMBOK® Guide Eighth Edition carries Manage Communications as the process of performing the work, and what it keeps pointing at is the receiving end: whether understanding and action resulted. The practical question is how much checking a particular message deserves, and that scales with what a misreading would cost.
At the low end, nothing at all. Most project traffic is context for people who need a rough sense of what is happening, and confirming receipt of it wastes their time and yours.
One step up, ask for a response only a reader could give. "Let me know if you have any questions" produces silence from the people who have not read it. "Can you tell me which of your two teams this affects" produces an answer that proves the message was read, and quite often corrects it.
A step further, get the action back in their own words. Before a cutover, the question worth putting to each team lead is what they will be doing at eleven o'clock, at midnight and at two. Asking somebody to describe their own actions surfaces a divergent reading in about thirty seconds, and it is the most valuable habit in this whole area.
At the top, where a misreading would cost a weekend or a regulatory breach, inspect the behaviour rather than the answer. Look at whether the schedule they published matches yours, whether the rota they issued covers the hours you need, whether the change request they raised says what you expected it to say. An artefact somebody else produced is better evidence of shared understanding than any words of confirmation they could offer.
Volume works against all four. Every extra message lowers the attention available for the one that matters, and a project sending four updates a week has trained its audience to skim. Deciding what not to send is part of managing communications, and it is the part that never appears in a plan.
What the cutover call actually fixed
That migration recovered in about four hours, which was luck as much as anything, since the failed load was caught by a checksum step that existed for an unrelated reason. What the team changed afterwards is the part worth keeping.
They added one item to the cutover process: a twenty-minute call at four o'clock on the Friday in which each of the six team leads said out loud what their team would be doing in each of the four overnight windows. On the first run, two teams described an overlap the runbook did not show, and one team described a step it had been performing for the previous two cutovers that nobody in the control room knew about.
Nothing new was communicated on that call. Everything said had already been issued, read and acknowledged. What the call did was turn the sending into a state somebody could inspect, and twenty minutes of six people talking found three divergences that a hundred pages of runbook had not.
For a PMP® candidate, the reading that helps is that a communication problem is diagnosed at the receiving end. A situation where the project manager can demonstrate that everything was issued, and something still went wrong, is asking which of the three failures occurred. The response differs in each case: a routing fix, a rewrite in the reader's terms, or a request that names a person and a date. Settle which of the three a situation describes, then decide what to do about it. Getting quick at that means meeting situations dressed up to look like a documentation problem, which is the sort of thing a structured PMP exam preparation course sets up.
Take on one habit and drop one thing. Take on the practice of asking people to describe what they will do, in their own words, before anything consequential happens. Then drop one of your regular sends. Most projects carry at least one report that was set up in month two and has never since been tested against whether anybody reads it, and its principal effect is to reduce the chance that the message that matters gets opened.
Interested in going further?
Everything issued, everybody acknowledged, and a team doing the wrong thing overnight is a combination most delivery people meet at least once. Omega's PMP® Exam Preparation works through situations where the communication record is complete and the understanding is not.
The PMBOK® Guide Eighth Edition is where the communications processes and the domain holding them are set out.
Ad · Amazon affiliate link.
References
A132: The PMBOK 8 Stakeholders Performance Domain: What It Really Covers
A133: Stakeholder Management vs Stakeholder Engagement
A134: Power/Interest Grid vs Salience Model
A135: Stakeholder Power Is Not the Same as Engagement
A136: Why Hostile Stakeholders Still Need Engagement
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
