5 Reasons MEP Coordination Fails — And What They Actually Cost You
- Maciej Grabowiecki

- Feb 1
- 4 min read
Updated: Mar 5
You’re three weeks from Stage 4 issue. The architect has changed the ceiling void height — again. Your Revit model is two iterations behind structures, and nobody can agree who owns the corridor risers. The coordination meeting is in an hour and the clash report is 400 items long, with no indication of priority.
If that feels familiar, this post is for you. Because most coordination failures aren’t caused by “bad engineers” — they’re caused by predictable breakdowns in ownership, information flow, and model quality.
Below are five common reasons MEP coordination fails on UK projects, what they look like in practice, and what they really cost when they make it to site.
1) Unclear Ownership of Coordination Responsibility
What it looks like
On multi-discipline projects, coordination responsibility often falls between roles:
“The BIM Coordinator will sort it” (but they don’t have authority to change design intent)
“The engineer owns it” (but they don’t have time to manage federated clashes)
“The contractor will resolve it” (but only once it becomes a site problem)
So clashes persist across design stages because “someone else” was supposed to resolve them.
The real cost
Rework across multiple disciplines (often repeated at every issue)
Programme delays at Stage 4/5 when changes are hardest
Blame cycles: design team vs contractor vs architect
Loss of trust: the model stops being treated as reliable coordination data
What good looks like
A simple, explicit ownership matrix:
Named owner per system (ductwork, pipework, containment, builders work openings)
A tracked resolution workflow with status and due dates
Clear “decision rights” (who can move what, and what requires sign-off)
Coordination works when accountability is visible and enforced — not assumed.
2) Coordination Starts Too Late (Treated as a Final Check)
What it looks like
Coordination is often postponed until “there’s enough design to coordinate”, usually due to fee pressure. The result: coordination becomes a late-stage clash exercise rather than an ongoing design process.
Typical pattern:
Stage 3: “We’ll keep it indicative”
Early Stage 4: “Let’s federate now”
Mid Stage 4: “We’re already behind”
Stage 5: “We’ll fix it on site”
The real cost
Clash resolution has a cost curve:
Early design adjustments are cheap (route changes, riser positioning, plant layout tweaks)
Late adjustments are expensive (redesign, redesign knock-on, re-issue, site delays, variations)
Late-stage coordination also forces poor compromises:
Reduced access zones
Crushed ceiling voids
Unbuildable containment routes
Fire strategy conflicts discovered too late
What good looks like
Start federated coordination early (even with partial models)
Keep the coordination “rhythm” consistent: weekly/fortnightly, not ad-hoc
Treat coordination as design development, not quality control at the end
3) Model Quality Issues That Cascade
What it looks like
Coordination is only as good as the models being coordinated. Common “silent killers”:
Inconsistent LOD/LOIN across disciplines
Placeholder families used beyond their intended stage
Incorrect element categorisation, offsets, or levels
Models not aligned to an agreed origin/coordinates strategy
Unrealistic routing allowances (ducts/pipework drawn “too perfect” with no supports, access, insulation, or builders work logic)
This creates two bad outcomes at the same time:
False clashes (noise) that waste time
Real clashes hidden inside the noise
The real cost
Coordination teams spend hours triaging junk
Real buildability issues slip through
“Clash fatigue” sets in: people stop believing the report
What good looks like
Model QA as a prerequisite, not an afterthought:
A defined modelling standard aligned to the project BEP
Clear LOD/LOIN expectations by stage
A quick “model health check” before clash detection (levels, coordinates, categories, key parameters, tolerances)
If the model quality is inconsistent, coordination becomes theatre.
4) No Structured Clash Prioritisation (Everything is “High Priority”)
What it looks like
You get a clash report with 800 items. It’s technically “complete”… and practically useless.
Teams either:
Ignore it (too overwhelming), or
Treat all clashes equally (wrong priorities)
Meanwhile, the truly critical issues (penetrations, riser conflicts, plant access, fire compartment interfaces) are buried under hundreds of low-impact clashes.
The real cost
Cosmetic items consume time while critical buildability issues remain unresolved
Structural penetrations get “discovered” late
Site teams improvise (and then you inherit the risk)
What good looks like
A triage method that prioritises by impact:
Buildability blockers: penetrations, major route conflicts, plant access/maintenance zones
Compliance risks: fire stopping strategy interfaces, smoke extract routes, critical life safety coordination
Programme risks: items affecting long-lead packages, builders work openings, main containment corridors
Cosmetic/low impact: minor soft clashes, tolerance overlaps, non-critical coordination zones
A clash report should function like a decision tool — not a dump of collisions.
5) Knowledge Loss Between Design Stages (and Between People)
What it looks like
Teams change. Freelancers rotate. Responsibilities shift between Stage 3 → Stage 4 → Stage 5.
And because coordination decisions are often made verbally (or buried in email), the context disappears:
Why that duct route was agreed
Which compromises were accepted and signed off
What assumptions were made about structure or architecture
Which “temporary” decisions became permanent
The real cost
Previously “resolved” issues get reopened
Duplicate effort and contradictory rework
Arguments about what was agreed (with no audit trail)
Delays caused by re-deciding old decisions
What good looks like
A single, continuous coordination record that travels with the project:
Decisions logged against the coordination item
Markups linked to tasks and outputs
Clear provenance: who asked for what, when, and why
In UK delivery, where ISO 19650-style information management is the expectation on serious projects, relying on memory and email threads is a structural weakness.
The underlying pattern
Most MEP coordination failures aren’t caused by bad engineers. They’re caused by bad systems:
unclear ownership,
late coordination,
inconsistent model quality,
unprioritised clash data,
and knowledge loss across stages.
Firms that coordinate well don’t just have better people. They have better methods — repeatable, auditable, and visible to the whole delivery team.
A soft next step (if you want it)
BIM Hives was built to address exactly these coordination breakdowns — with structured task ownership, tracked resolution, and a continuous coordination record inside a portal workflow.
If you want to see what that looks like in practice, book a short walkthrough and I’ll show you how we structure MEP coordination delivery end-to-end Book a call

Comments