top of page
Search

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

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:

  1. False clashes (noise) that waste time

  2. 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


 
 
 

Recent Posts

See All

Comments


© 2026 BIM Hives All Rights Reserved. BIM Hives is a trading name of GxM Consulting Ltd. Company No. 11029452

bottom of page