Most construction clashes are not discovered on site, they are created there , because the right checks were never done early enough, or done with the wrong intent. While clash detection is often treated as a BIM coordination exercise, its real purpose is far more practical: preventing field stoppages, rework, and unsafe improvisation .
A model that is “clash-free” in software does not automatically mean it is constructible . Field teams encounter issues not because clashes were missed, but because the wrong types of clashes were checked , or checks were performed too late.
This article explains how clash detection should be structured for BIM-to-field workflows, what must be checked before construction begins, and how to align clash protocols with real execution needs.
1. Why Traditional Clash Detection Fails the Field
Typical clash detection focuses on:
Hard clashes between geometry
Discipline-to-discipline interference
Visual coordination reviews
While necessary, this approach misses critical realities:
Installation sequences
Access requirements
Temporary works
Construction tolerances
Reality capture deviations
As a result, teams declare models “coordinated” while field teams struggle.
Clash detection must evolve from design coordination to execution readiness .
2. The Four Types of Clashes That Matter on Site
A field-ready clash detection strategy includes four distinct clash categories .
1️⃣ Hard Clashes (Geometry vs Geometry)
These are direct physical overlaps:
Ducts intersecting beams
Pipes passing through columns
Equipment colliding with structure
Field impact: Immediate installation failure
Hard clashes must be resolved early, but resolving only these is not enough.
2️⃣ Clearance & Access Clashes
These are often ignored in early coordination.
Examples:
Insufficient maintenance clearance around valves
Equipment installed too close to walls
No access for tools or lifting
Code-mandated clearances violated
Field impact:
Unsafe installations
Delayed inspections
Future maintenance issues
Clearance clashes directly affect operability, not just construction.
3️⃣ Sequence & Temporary Works Clashes
These clashes occur over time, not space.
Examples:
Installing MEP before structural elements are accessible
Temporary scaffolding blocking permanent installations
Crane paths intersecting installed elements
Formwork interfering with embedded services
Field impact:
Rework
Schedule overruns
Unsafe site improvisation
These clashes only emerge when BIM is linked to 4D sequencing .
4️⃣ Reality vs Design Clashes
These are increasingly critical.
Examples:
As-built structure deviating from design
Existing utilities not matching drawings
Terrain variations affecting foundations
Tolerance stack-ups
Field impact:
Forced on-site design changes
RFIs during construction
Cost escalation
Reality capture must be part of the clash process, not a separate workflow.
3. When Clash Detection Should Happen
Timing is as important as technique.
Design Stage
Resolve major hard clashes
Establish system zones
Pre-Construction
Validate clearances
Confirm installability
Integrate survey and scan data
Construction
Perform rolling clash checks
Compare as-built vs design
Validate future work zones
Clash detection is continuous , not a one-time milestone.
4. Tolerance Is Not Binary
Many clashes exist because tolerance is ignored.
Example:
A 10 mm overlap in software may be acceptable
A 10 mm misalignment in prefabrication may not
Field-ready clash detection:
Defines acceptable tolerances
Applies them consistently
Differentiates between critical and non-critical clashes
Not all clashes deserve equal attention.
5. Who Should Be Involved in Clash Reviews
Effective clash detection is multidisciplinary.
Beyond BIM coordinators, involve:
Construction managers
Site engineers
Safety officers
MEP supervisors
Fabrication partners
If the people who build are not in the review, constructability is assumed, not verified .
6. Tools Are Secondary to Rules
Navisworks, Solibri, BIMcollab, Revizto, tools matter, but only after protocols are defined.
Field-oriented protocols include:
Clash priority rules
Discipline ownership
Resolution deadlines
Verification steps
Field validation loops
Without rules, tools generate noise instead of insight.
7. Clash Detection and the CDE
Clash outputs must:
Live inside the CDE
Be linked to model versions
Carry status and responsibility
Be visible to the field only when resolved
Unresolved clash reports should never reach site teams.
8. The Cost of Skipping Execution-Level Clash Checks
Projects that skip field-oriented clash detection experience:
Higher RFI volume
Increased site stoppages
Poor prefabrication success
Compromised safety
Delayed commissioning
Most of these costs are invisible until construction is underway.
9. A Practical “Go-to-Site” Clash Checklist
Before any model is released for construction, confirm:
✔ Hard clashes resolved
✔ Clearances verified
✔ Access paths validated
✔ Temporary works reviewed
✔ Sequence conflicts addressed
✔ Reality capture aligned
✔ Tolerances agreed
✔ Field teams briefed
If even one item is missing, the model is not site-ready.
Conclusion
Clash detection is not about proving coordination, it is about protecting execution .
When clash protocols are aligned with field reality:
Installations flow
Safety improves
Rework drops
Schedules stabilize
Trust in BIM increases
A model that survives real-world construction is not “clash-free.”
It is execution-ready .
