Why Your Clash Detection Report Is Not Solving Your Field Coordination Problems

If your Navisworks clash report is 300 items long and growing, and the mechanical and electrical subcontractors are still calling each other on site to figure out who moves their pipe, the problem is not Navisworks. The problem is that running clash detection is not the same as coordinating a project.

The two are frequently confused. The result is a process that produces reports nobody acts on, meetings where trades talk past each other, and conflicts that get resolved in the field by whoever is working that day — which is the most expensive and least controlled way to resolve them.

What Clash Detection Actually Does

Clash detection identifies geometric intersections between elements in a federated model. It tells you that a duct and a pipe occupy the same space. It does not tell you which trade moves, where they move it, how that affects the adjacent structure, or what sequence the resolution needs to happen in to support the construction schedule.

That determination requires human judgment, coordination authority, and a process for tracking resolution to the field. Clash detection produces the input list. Coordination produces the answers.

The Most Common Process Failures

Clashes Are Not Prioritized by Construction Sequence

A 300-item clash report sorted alphabetically by trade is not useful. The clashes that matter are the ones in the areas where work is starting in the next four weeks. Prioritizing by construction zone and sequence is what separates a coordination process that supports the schedule from one that runs parallel to it.

No Single Point of Coordination Authority

When a clash is identified, someone needs to make a decision. If there is no BIM coordinator with authority to direct the resolution — if every conflict becomes a committee discussion — the process slows to the point where it no longer leads the construction sequence.

Resolutions Are Not Verified Against Updated Models

A clash marked resolved in the log should mean the model has been updated to reflect the resolution, and that update has been re-federated and re-checked. If resolutions are tracked only in a spreadsheet without model verification, you have no way to know whether the field direction is actually conflict-free.

What a Working BIM Coordination Process Looks Like

Effective coordination has four components: a federated model that is updated on a defined schedule, a clash log organized by construction zone and priority, weekly coordination meetings with decision authority present, and a verification step that confirms every resolution is reflected in the model before field direction is issued. The process leads the construction schedule by at least two to four weeks. If it is not leading the schedule, it is not coordinating the project.

Clash Severity Is Not All Equal

Treating every item in the clash report as equally urgent is one of the fastest ways to bury a coordination process under its own volume. Clashes generally fall into three categories, and they require different responses.

Hard Clashes

Two physical elements occupy the same space — a duct and a structural beam, a sprinkler main and an electrical conduit rack. These are unambiguous and must be resolved before fabrication or installation. They are the ones that stop work in the field if missed.

Clearance Clashes

Elements do not physically overlap but violate a required clearance — access space for a valve, service clearance in front of an electrical panel, insulation thickness around a chilled water line. These are frequently missed because the geometry looks clean at first glance; they require clearance zones to be modeled explicitly, not inferred.

Workflow Clashes

No physical conflict exists, but the installation sequence implied by the model is not constructible — a ceiling grid modeled before the sprinkler heads it needs to accommodate, or a wall type that would have to be built around already-installed ductwork. These clashes never show up in an automated Navisworks or Solibri run because there is no geometric intersection to detect. They surface only when someone with field sequencing experience reviews the model against the construction schedule.

A coordination process that only tracks hard clashes is solving roughly a third of the actual problem. The clearance and workflow categories are where most of the field friction that automated reports miss actually originates.

Setting LOD Expectations by Phase

Level of Development (LOD) expectations should be defined in the BIM Execution Plan before coordination starts, not discovered mid-project when a subcontractor's model turns out to be LOD 200 when the coordination process needed LOD 350. Design-phase models are typically adequate at LOD 300 for spatial coordination. Fabrication-level coordination — the point where clash resolution actually protects field installation — requires LOD 350 to 400, meaning connections, supports, and access requirements are modeled, not just the primary geometry. If the BIM Execution Plan does not specify LOD by trade and by milestone, the coordination team ends up negotiating model quality clash by clash instead of enforcing a standard set at the start.

Measuring Whether Coordination Is Actually Working

The clash log itself is a lagging indicator — it tells you what was found, not whether the process is functioning. The leading indicator that matters is field RFIs tied to coordination issues that should have been caught in the model. If RFIs referencing spatial conflicts, access clearances, or sequencing problems are still arriving at a steady rate after the coordination process is supposedly complete, the model federation cadence, clash prioritization, or LOD requirements were not adequate — regardless of how clean the final clash log looks. Tracking coordination-related RFIs as a distinct category, separate from design-intent RFIs, is the single most reliable way to know whether the BIM process is actually preventing field problems or simply documenting them after the fact.

One further discipline worth building into the process: log the trade responsible and the root cause category — design coordination gap, late model update, or missed clearance — for every resolved clash. Over the life of a project this creates a pattern. If one trade or one model author is consistently the source of late-discovered conflicts, that is a resourcing or process conversation worth having directly, rather than continuing to absorb the coordination cost silently through the clash log.