Talk When the Work Talks

Communication planning for the project manager. How a work plan sets the shape of a communication plan, and why a repeating calendar cannot.

Module Home  ›  Module Overview

Every Tuesday at nine

On the Oakhaven Public Safety Campus, the project team meets every Tuesday at nine, and it has met every Tuesday at nine since the day of kickoff. The agenda is stable, attendance is good, and the notes go out the same afternoon.

But the mechanical routing decision that Construction Documents depends on has been open for three weeks, and it has never appeared on an agenda.

The calendar is working exactly as designed. The project is losing three weeks anyway, and the calendar is the reason nobody noticed.

This lesson converts the work plan built in Module 5 into the communication plan that the kickoff will announce in Module 7. It was prepared to give Grace project managers and aspiring project managers a standardized method for setting communication intensity against work intensity, and for anchoring every scheduled conversation to a coordination milestone or a client decision point rather than to a repeating date.

1

THE BRIDGE

Communication planning and the work plan

Module 5 produced a work plan that names every task, assigns it to a role, estimates it in hours, and links it to the tasks that depend on it. Module 7 runs the kickoff, where a project manager tells the team and the client how the project will be run. Module 6 is the conversion between them.

Almost nothing in a communication plan is invented. The meetings, the reviews, and the decision dates are all already present in the work plan, carried in the dependencies between tasks and in the moments where the client has to choose. The work of this module is reading them out and putting them on a calendar in the right order and at the right density.

The work plan tells a project manager when to talk.

Remember: a communication plan is derived from a work plan. Any plan that could have been written before the work was planned is a calendar wearing the name.
2

THE PROBLEM

Why does a recurring meeting calendar fail?

A recurring calendar sets one rate and holds it. A weekly internal check in, a biweekly client call, and a monthly report will run at that same rate in week two, when four people are working and nothing has been decided, and in week eleven, when fourteen people are working and three disciplines are waiting on the same answer.

The consequence runs in both directions at once. Early in a project the fixed cadence produces meetings with little to decide, which teaches the team that these meetings are optional. Later, at the point of highest coordination load, the same cadence provides a fraction of the exchange the work requires, and the team has already learned to treat it lightly.

Coordination that the work plan required and the calendar never scheduled does not disappear. It is deferred, and it is paid later, in rework, at the rate Module 2 priced. Grace calls that gap communication debt.

COMMUNICATION DEBT

Coordination the work plan required and the calendar never scheduled. It is settled later, as rework, at approximately 2.75 times the wage per hour and against a fee that has not grown.

?Reflect

Think of the last project where a decision sat open longer than it should have. Was there a recurring meeting running the entire time it sat open? Now consider what would have had to be true for that decision to reach an agenda.

On most projects the recurring meeting was running the whole time, which is the point. A standing agenda reports on work in progress and rarely creates the obligation to close an open item. A decision reaches an agenda when someone has written down the date it must be made and has scheduled the conversation backward from that date.
Remember: a fixed cadence is over engineered where the project is quiet and under engineered exactly where it is fragile.
3

THE SHAPE

How should communication intensity follow work intensity?

Modules 2 and 5 both end at the same curve. Effort starts slowly while uncertainty is high, rises through the middle once the key decisions are locked, and eases late as the work moves into review. Coordination load follows that curve, because coordination is a function of how many people are working and how many handoffs sit between them.

Communication intensity should therefore take the same shape the effort takes. Intensity is not the same as frequency, since a forty five minute coordination working session and a status email are not equivalent events, and a plan that counts them equally is not measuring anything.

The practical form of this is three zones. The opening zone carries few touchpoints at high depth, because the decisions made there set everything downstream. The middle zone carries the most touchpoints, because the most disciplines are working at once. The closing zone reduces in number and shifts in kind, from coordination toward review and approval.

Zone Effort Touchpoint count Dominant kind What fails here
OpeningLow and risingFewDecision framingDecisions framed too late to be cheap
MiddleHigh and sustainedMostCoordination working sessionsHandoffs happen by email and drift
ClosingFallingFewerReview and approvalReview time is not scheduled and compresses
Figure 1. Communication intensity across the three zones of a project.

Shape accounts for half of the problem. The other half is magnitude, and magnitude is set by how many parties have to coordinate directly. The number of channels between parties rises as n(n−1)/2, so five parties carry ten channels, ten parties carry forty five, and twenty parties carry one hundred ninety. Adding four people to a team of six does not add four conversations. It adds thirty nine.

A project manager who plans only the calendar treats that channel count as fixed and asks how many meetings will cover it. On a large project no achievable number does. A project manager who plans the structure changes the count itself, routing coordination through discipline leads so that exchanges pass through a small number of hubs rather than crossing every pair. The channel count then falls toward n−1, and a load no calendar could carry becomes one a reasonable calendar can.

TWO DECISIONS, NOT ONE

Communication planning answers when to talk and who has to talk to whom. The first decision sets the calendar. The second sets how much calendar the project needs. Where the party count is high, the second decision carries more of the load than the first.

Remember: match the shape of the communication to the shape of the work, size it to the number of interfaces the team actually holds, and the calendar becomes an output rather than an assumption.
4

TRIGGER ONE

What is a coordination milestone?

A coordination milestone is a point at which two or more disciplines must exchange information before either can proceed. Every one of them is already written in the work plan, carried in the dependency links between tasks that belong to different roles.

Finding them is mechanical. Read the work plan for any task whose predecessor sits with a different discipline, mark the point where the handoff occurs, and schedule a working session at that point rather than a status update near it.

The distinction between a working session and a status meeting is the one most plans miss. A status meeting reports what has happened. A working session produces a decision or an exchange that the next task requires, and it ends with something written down. Only the second kind clears a coordination milestone.

COORDINATION WORKING SESSION

Attendance is limited to the disciplines on both sides of the handoff. It has one named output. It ends when that output exists, and the output is recorded the same day.

Remember: a status meeting reports on a handoff. A working session performs one.
5

TRIGGER TWO

When must a client decision be set?

A client decision point is any moment where the client must choose between defined options for the work to continue. Each one carries a date, and that date is calculated backward from the task that depends on the choice rather than forward from the moment the question is asked.

Every client also has a decision latency, meaning the elapsed time between being asked and answering. Latency is a property of the client and of the size of the decision, it is observable from the history of previous projects, and it therefore belongs in the plan as an input.

Request by date = decide by date − client decision latency

Consider the Oakhaven mechanical routing decision. Construction Documents cannot start the affected package until routing is fixed, that package begins in week eleven, and the client has historically taken about three weeks on decisions of this size. The request therefore had to be made in week eight, framed with options and a recommendation, and it was made in week eleven instead.

A decision that slips leaves a project manager three options, and choosing silently is not one of them. Hold the work and absorb the schedule, proceed on a documented assumption and price the risk of rework, or reduce the scope of the decision so that a smaller choice unblocks the larger one.

?Reflect

Think of a client you work with now. From memory, how long do they usually take to return a decision that requires more than one person to agree? Now consider the next decision you will need from them, and count backward from the date the dependent work starts.

Whatever number you named is your planning input, and most project managers can produce it immediately, which shows the information was always available. The value of writing it down is that it moves the request date from instinct into the plan, where the rest of the team can see it.
Remember: a decision requested on the date it is needed has already slipped by the length of the client latency.
6

THE METHOD

How does a project manager build the plan?

The build runs in six steps, and it starts from the Module 5 work plan rather than from a blank calendar.

  1. Plot the effort curve by phase, using the phasing from the work plan.
  2. Mark every dependency that crosses a discipline, and convert each into a coordination milestone with a named output.
  3. Mark every point where the client must choose, and calculate a decide by date backward from the dependent task.
  4. Subtract the client decision latency from each decide by date to produce a request by date.
  5. Set touchpoint density by zone so that the count of touchpoints follows the effort curve rather than a fixed interval.
  6. Name an owner, an audience, and a written output for every touchpoint, then publish the result on one page.

The output of the sixth step is the page a project manager presents at kickoff. Module 7 covers how that page is introduced and how the team is held to it.

Remember: the one page communication plan is an output of the work plan, and it is the document the kickoff exists to announce.
7

THE PATTERNS

The four patterns in communication

The project manager running Oakhaven every Tuesday at nine is the first pattern below, and the work of this module is moving to the last while avoiding the two failure modes in between.

The Calendar Keeper

Sets a cadence at kickoff and never revisits it. The blind spot is that the cadence is identical in the quietest and the busiest week of the project. The preferred behavior is resetting density at every phase change.

The Broadcaster

Communicates constantly and closes nothing. The blind spot is treating volume as alignment, so decisions stay open while everyone feels informed. The preferred behavior is ending every touchpoint with one written output.

The Firefighter

Communicates when something breaks. The blind spot is that the client only hears from the project manager during a problem, which spends trust on recovery. The preferred behavior is scheduling the decision before it becomes an escalation.

The Deliberate Communicator

Reads the work plan, schedules against coordination milestones and client decision points, and moves intensity with the work. The standard is a plan whose shape a stranger could predict from the effort curve alone.

Remember: a green calendar is not evidence of alignment. Closed decisions are.
8

SUMMARY

Summary

This lesson followed one open mechanical routing decision on the Oakhaven Public Safety Campus from the recurring meeting that never surfaced it, through the effort curve that should have set the coordination density, to the decide by date that would have made the request three weeks earlier. The same method applies to every project Grace delivers, and the figures change with the client and the phase.

The Module 6 Quick Reference documents the six step build, the decide by calculation, and the one page template, for use on the job. The Communication Load Curve lets a project manager test a cadence against a real effort curve before committing to it.

In Module 7, project managers present this one page plan at kickoff and set the expectations that hold the team and the client to it.

Remember: plan the conversation where the work concentrates, and where the client has to choose.

PUT IT TO WORK

On your throughline project

  1. Open your Module 5 work plan and mark every dependency that crosses a discipline.
  2. Pick the next client decision your schedule depends on, and write the date the dependent work starts.
  3. Subtract your client's usual decision latency from that date. If the result is in the past, you are already late and the plan should say so.
  4. Count your scheduled touchpoints in your busiest month and in your quietest month. If the two counts are the same, you have a calendar rather than a plan.

The Communication Load Curve tests a cadence against a real effort curve. The Quick Reference carries the six step build and the one page template.