When a project escalates to Exco, the diagnosis is almost always the same: a communication breakdown. The client was not kept informed. The PMO was not aware of the risk. Sales had no visibility into delivery status until the complaint arrived.
The response is also almost always the same: communicate more. More frequent updates. More stakeholder touchpoints. More status meetings.
This is the wrong intervention. Not because communication is unimportant — it is fundamental — but because more communication applied to unclear governance produces more noise, not more clarity. The escalation was not caused by a frequency problem. It was caused by a structural problem that communication volume cannot fix.
What communication is being asked to do
In most project environments, communication is carrying a load it was never designed to carry.
It is being used to compensate for undefined ownership — if nobody is clear on who is accountable, frequent updates create the appearance of control. It is being used to manage expectations that were never formally set — if scope was not agreed in writing, regular contact substitutes for a documented baseline. It is being used as an early warning system for risks that were never formally identified — if there is no RAID log, a phone call to the client becomes the mechanism for surfacing what should have been tracked from week one.
When communication is doing all of this, it is not functioning as communication. It is functioning as a workaround for missing governance infrastructure. And workarounds scale badly. They depend on the skill, judgment, and availability of individual project managers. They break when those individuals change. They produce inconsistent outcomes across projects and across teams.
The question is not how to communicate better. It is what communication is supposed to be carrying — and whether the governance structure underneath it makes that possible.
The three communication failures that precede every escalation
Project escalations rarely arrive without warning. In retrospect, the signals were present. What was missing was the structural mechanism to surface them before they reached the client or leadership.
The first failure is client communication without a defined escalation threshold. A weekly status report that does not specify what triggers a change in RAG status, or what action a RED status requires from which named owner, is not a governance document. It is a record. Records do not prevent escalations. Defined escalation criteria do.
The second failure is cross-functional communication without ownership. Projects that span delivery, sales, and operations require clear handoff points — moments where one function's accountability ends and another's begins. When those handoff points are not documented, communication between functions becomes dependent on relationships rather than agreements. Information reaches the wrong people, arrives too late, or does not arrive at all — not because individuals are negligent, but because there is no defined channel and no defined owner for the handoff.
The third failure is stakeholder communication without a baseline. Stakeholder expectations cannot be managed if they were never formally set. When scope is agreed verbally, or documented in a proposal but never converted into a signed project baseline, every project update is an interpretation. The client interprets progress against what they expected. The project team reports against what was scoped. The gap between those two positions is where disputes originate — and no volume of communication closes a gap that was structural from the start.
What effective PM communication actually requires
Effective communication in a project environment is not a soft skill. It is a governance output. It is what happens when the underlying structure — ownership, scope baseline, escalation criteria, decision rights — is in place and operational.
A communication plan that works does not describe how often updates will be sent. It describes who owns each communication type, what information it must contain, what triggers a change in format or frequency, and who is responsible for acting on the information received. It is a decision document, not a schedule.
A stakeholder map that works does not list names and roles. It documents what each stakeholder needs to know, when they need to know it, and what decision or action their awareness is intended to enable. It distinguishes between stakeholders who need to be informed and stakeholders who need to approve — because the communication requirement for each is fundamentally different.
An escalation path that works does not rely on a project manager's judgment about when to escalate. It defines the conditions that trigger escalation, the person to whom escalation is directed, the timeframe within which a response is required, and what happens if no response is received. It removes the dependency on individual discretion and replaces it with a documented, repeatable process.
None of these require new tools. They require explicit decisions — about ownership, thresholds, and accountability — that most project environments have never formally made.
Why this matters beyond the project
The consequences of communication failures in project delivery do not stay inside the project. They surface in the relationships between functions that the project depends on.
Sales commitments made without delivery input create scope baselines that the project team cannot execute against. Delivery escalations that reach the client before they reach the PMO damage the organisation's credibility with accounts it needs to retain. Cross-functional disputes about ownership — who should have communicated what, to whom, and when — consume leadership time and produce defensive behaviour rather than resolution.
These are not project problems. They are organisational governance problems that become visible through projects. The project is where the structural gap surfaces. It is rarely where the structural gap originates.
This distinction matters because it shapes the intervention. Coaching project managers to communicate better does not close an organisational ownership gap. Introducing a new project management tool does not resolve an undefined escalation path. Training a team on stakeholder management does not produce a signed scope baseline where none exists.
The intervention must address the structural conditions — the ownership clarity, the decision rights, the documented escalation criteria — that make effective communication possible in the first place. Without those conditions, communication will continue to carry the load it was never designed to carry, and escalations will continue to arrive as surprises.
The starting point
Before any communication improvement initiative, before any new reporting framework, before any stakeholder engagement programme — the question to answer is whether the governance conditions that effective communication depends on are actually in place.
Is ownership clear at every handoff point? Is the scope baseline documented and agreed? Are escalation criteria defined, or are they left to individual judgment? Does every stakeholder know what they are expected to do with the information they receive?
If the honest answer to any of these is no, the communication problem is not a communication problem. It is a governance problem wearing a communication problem's clothes.
That is where the assessment starts.
"More communication applied to unclear governance produces more noise, not more clarity."