CONTACT US
CONTACT US

Why A Clash Report Does Not Prove That Your Project Is Coordinated

A clash count is not coordination. Why 3,800 resolved clashes still produce site conflicts, and what a genuinely coordinated BIM model requires.

BIM

8/7/20266 min read

A coordination model is run. The clash-detection software returns a number: 3,800 clashes. Someone places that number in a report, the report goes to the client, and everyone moves on to the next milestone.

Then the project reaches site, and issues that were supposedly “resolved” appear anyway: a duct cannot clear a beam, a valve cannot be accessed, or the planned installation sequence does not work.

The clash report existed. It did not prevent the problem. Here is why—and what needs to happen instead.

A raw clash count measures software output, not coordination quality

Clash-detection tools compare model geometry and identify intersections or proximity violations according to configured rules. However, the initial count may be inflated by duplicate reports, self-intersections within a single model, intentionally modelled intersections, unsuitable tolerances, and repeated clashes caused by the same underlying issue.

A high raw count should therefore be treated as an initial workload indicator, not as a direct measure of project risk. The result should be filtered, grouped and reviewed by competent coordinators before it is reported as a coordination metric.

The filtering process should normally include:

  • Removing duplicate results and grouping related clashes into one issue.

  • Separating genuine inter-discipline clashes from self-intersections and modelling errors.

  • Applying agreed tolerances appropriate to the project, system and construction method.

  • Distinguishing design decisions from genuine coordination failures.

  • Assigning an owner, priority, required action and target date to each issue.

  • Verifying that a reported resolution has actually been incorporated into the current model revision.


The more meaningful metrics are not simply “clashes found” and “clashes closed.” A client should also see the number of high-priority open issues, the age of unresolved issues, the number reopened after review, and whether critical issues were resolved before the relevant trade reached site.

Three types of coordination problem

Clash-detection software primarily identifies geometric interference. A complete coordination process must also consider clearances, access and construction sequence.

Hard clash

Two physical elements occupy the same space—for example, a duct passing through a structural beam. This is the type of issue most commonly identified by conventional geometric clash detection. The solution may involve rerouting, resizing, repositioning or redesigning one of the elements.

Soft clash

The elements do not necessarily overlap, but the required clearance or access zone has not been maintained. Examples include insufficient space for pipe insulation, inadequate access to a valve, or insufficient maintenance clearance in front of equipment.

These issues may be identified through clearance rules, clearance volumes, equipment access zones or dedicated model-checking procedures. They will not necessarily appear in a standard geometry-only clash test unless the required clearance has been explicitly modelled or configured as a rule.

Workflow or sequencing clash

The final geometry may be acceptable, but the planned installation sequence is not. For example, a service may need to be installed before a ceiling or wall is closed, or two trades may require the same work zone during overlapping activities.

This type of issue requires the model to be reviewed against the construction programme, logistics plan, work packages and installation methodology. It is commonly associated with 4D planning and cannot be identified reliably through a geometry-only test.

A coordination process that tracks only hard clashes is addressing only one part of the coordination risk.

First, make sure the models describe the same place

Every clash review assumes that the linked models are correctly positioned relative to one another. If the models use inconsistent origins, units, rotations or coordinate systems, the federated model may produce misleading results—or fail to show genuine clashes.

For example, the architectural model may have been started using a convenient local origin, while the structural model is based on the site survey. If the MEP model is then linked using different coordinates or rotation settings, the models may appear displaced or misaligned.

In this situation, the problem is not that every reported clash is “technically real.” Rather, the federated model is not a reliable representation of the project, so both positive and negative clash results may be unreliable.

ISO 19650 establishes principles for information management, including information requirements, information standards, production methods and procedures, reference information, shared resources and the common data environment. It does not prescribe one universal project-base-point arrangement or a single coordinate-management method for every project. The project team must define and document the appropriate arrangement in the project information requirements, information standard, BIM Execution Plan or related project documentation.iso+1

Before modelling begins, the project team should agree and document:

  • The project coordinate system and units.

  • The relationship between the project origin, survey point and local model origins.

  • The required rotation and relationship to true north or project north.

  • The procedure for issuing and updating shared coordinates.

  • The person or organization responsible for maintaining the coordinate information.

  • The method for testing models before federation.

A simple test—placing a reference or dummy element at a known coordinate and confirming that every discipline’s model places it consistently—can identify a serious setup problem before it affects weeks of coordination work.

If the BIM Execution Plan does not clearly identify the coordinate strategy, model-alignment procedure and responsible parties, the issue should be raised before the first federated model review.

Where LOD fits

Level of Development should not be treated merely as a ladder of increasing geometric detail. The BIMForum LOD Specification is intended to clarify the expected characteristics of model elements and to improve communication between the project owner and project team. It also notes that teams should clarify whether they are using Level of Development or Level of Detail in their project BIM documentation.bimforum

In general terms:

  • LOD 300 indicates that an element is represented with sufficient graphical and non-graphical information for design coordination and documentation, subject to the project’s requirements.

  • LOD 350 adds information about interfaces with other building systems. It can support more detailed coordination, including the representation of relevant connections, supports, penetrations and other interfaces where required by the project.

  • LOD 400 represents an element with sufficient detail for fabrication, assembly and installation, where that level is required and defined by the project information requirements.

  • LOD 500 refers to a field-verified condition. It is not simply a higher level of design detail and should not automatically be treated as synonymous with every type of “as-built” model.


LOD 350 is therefore often relevant to detailed multidisciplinary coordination, but clash resolution is not restricted to LOD 350. Coordination should begin as soon as the models contain enough reliable information to support the required decisions, and the required level should be defined by the project’s information requirements and delivery milestones.

LOD 500 cannot normally be produced as a field-verified condition before the relevant asset has been constructed or installed. However, the exact verification method, accuracy, tolerance and supporting evidence should be defined in the project requirements. Laser scanning may be an appropriate method, but it is not automatically required in every LOD 500 deliverable.

A scope that requests “LOD 500 design models” before construction may therefore be using the term incorrectly. The better approach is to specify the required design or construction information level during delivery and define the field-verification requirements for the record or asset information model at the appropriate stage.

The following project statement should also be verified before publication:

AcouBIM Engineering is currently delivering LOD 500 as-built modelling on a multi-building entertainment project in Saudi Arabia, verified against laser-scan survey data to a stated tolerance.

If this statement is accurate and approved for external use, it is a useful practical example. Otherwise, it should be removed or rewritten as a general example.

What to ask before the next clash report

Four questions can distinguish a useful coordination process from one that simply produces an unreliable number:

  1. Is the raw clash count being filtered for duplicates, self-intersections, intentional intersections and unsuitable tolerances?

  2. Are clearance, access and maintenance requirements being checked, or are only hard geometric overlaps being reviewed?

  3. Is the model being checked against the construction programme, logistics plan and installation sequence?

  4. Does the BIM documentation define the coordinate strategy, model-alignment procedure and verification test?

You may also ask:

  • Are every issue’s owner, priority, target date and status recorded?

  • Are closed clashes being verified against the latest model revision?

  • Are repeated or reopened clashes being analysed for their underlying cause?

  • Are critical issues resolved before the affected trade reaches site?

If the answer to any of these questions is no, the clash report may be accurate as a software output—but it is not measuring the project’s actual coordination readiness.

AcouBIM Engineering is a BIM coordination and acoustics consultancy based in Ajman Free Zone, working across the UAE and Saudi Arabia. If your coordination process is producing clash reports that do not translate into fewer problems on site, get in touch at:
info@acoubim.com · +971 58 563 0037 · www.acoubim.com.