Communication Models
General technique · See it on the map
Guide only — A conceptual model, not a computable procedure.
Tracing how a message actually moves from one person's mind to another's, to see where it broke down.
When to use it
A message was sent and didn't have the intended effect, and you need to diagnose where it broke down — was it poorly encoded (jargon the receiver didn't share), lost to noise (sent during a reorg nobody was paying attention to), or delivered with no feedback loop to confirm it landed.
When to avoid it
As a substitute for actually sending the message — the model is a diagnostic tool for failures, not a communication method in its own right. Don't reach for it on routine, working communication that doesn't need diagnosing.
Steps
What it produces
- A diagnosis of where a communication broke down, and a specific change to how future messages of that kind are sent.
Common pitfalls
- Treating every miscommunication as a receiver problem ('they didn't read it') when the failure was in encoding or medium.
- Skipping the feedback step entirely and having no way to know a message landed until the resulting confusion shows up downstream.
- Using the model as an excuse rather than a diagnostic — naming 'noise' without identifying what the actual noise was.
Worked example
A subcontractor keeps missing a submittal deadline the PM is sure was communicated clearly. Walking it through the model, she finds the deadline was buried in paragraph four of a long email (encoding failure) sent the same week the sub was mobilizing a new crew (noise), with no reply requested (no feedback loop). She switches to a one-line subject-line deadline with a required acknowledgment.
Source
- PMBOK-6 §10.1.2.4
Where it comes from: this technique is named by the PMBOK Guide, 6th edition.