BIM Clash Detection for Construction Managers: Checklist and Issue Log

Clash detection is a test; clash management is a decision process

A federated BIM model combines architecture, structure and building-services models to check their interfaces. Hard clashes are geometric intersections; clearance checks test agreed installation or maintenance space. Sequence conflicts require a construction-sequence review rather than geometry alone. Define the model revisions, shared coordinates, element pairings, check rule, units and exclusions before running the tests. Use project-specific tolerances agreed with the responsible designers; there is no universal clearance value that makes every interface buildable. Detected results remain candidates for review, not verified construction defects.

The construction manager's task is to connect each material issue to a work front, a decision deadline and an approved information release. A duct intersecting a beam is urgent if fabrication starts next week; a similar conflict in a distant phase may be less urgent. The purpose is to protect buildability and programme certainty, not to achieve an impressive zero-clash dashboard.

Clash detection checklist: scope, tolerances and priorities

Start with a consistent model-checking scope: current model revisions, shared coordinates, agreed tolerances, discipline pairings and exclusions. Group duplicate results arising from the same physical interface. Then assess the remaining issues against their impact on safety, structural integrity, fire strategy, access, maintainability, procurement and the construction sequence.

Keep one traceable record per coordination decision: issue ID, location, discipline interface, model revision, check rule, priority, accountable owner, deadline, proposed action, required approval and verification evidence. The sample CSV contains illustrative issues, not a record of completed project outcomes. Replace them with your own verified information. Design responsibility stays with the appointed designer; the construction project manager coordinates the decision and its release deadline. Download the sample BIM clash issue log (CSV)

• Critical: unsafe or impossible work, statutory conflict or imminent critical-path installation.
• High: likely redesign, fabrication change, access loss or cross-trade delay.
• Routine: resolvable in the planned coordination cycle without delaying a release.
• False positive or duplicate: record the reason and close it without inflating performance claims.

BIM validation for architects: check the model before coordination

Architectural model validation asks whether the information being issued is suitable for its agreed purpose. Clash detection is one spatial test within that review. A file can contain no detected intersections yet still have misplaced storeys, missing properties, inconsistent schedules or the wrong revision. Check the architectural export before relying on a federated coordination result.

Separate model checks from design approval

Agree the intended exchange, applicable elements, required information and responsible reviewers in the project information requirements and BIM execution plan. Some tests can be automated; design adequacy, installation practicality and project approvals still need the appointed people. Passing a model rule does not itself approve a design or establish regulatory compliance.

1. Model provenance. Record the authoring model and exported file revisions, export settings, checker version and review scope. Evidence to retain: The reviewer can reproduce the checked information set; superseded files are excluded.
2. Placement and units. Check the agreed reference point, orientation, storeys and units using known control elements. Evidence to retain: The export aligns with the agreed reference; discrepancies have an owner before federation.
3. Rule applicability. List which element types, locations and delivery stage each requirement applies to. Evidence to retain: Included and excluded elements are explained; an empty result is not automatically a pass.
4. Required information. Test the presence and permitted value of each agreed property, with units or classification where relevant. Evidence to retain: Missing, invalid and not-applicable values are distinguished and traceable to the requirement.
5. Model and document consistency. Sample checked element IDs against the current schedule, drawing and approved design information. Evidence to retain: The sampled references agree or an exception records the discrepancy and responsible designer.
6. Correction and retest. Re-export a corrected test element and rerun the same rule set against the new revision. Evidence to retain: The issue links the failed check, authorised correction, new revision, retest evidence and reviewer decision.

Worked example: a missing door property

Illustrative test only: the agreed exchange requires a project-defined FireRating property on a selected set of doors. Door D-L02-014 falls within that scope, but its exported record has no value. Record an information failure against the requirement and element ID; do not invent a rating or conclude that the installed door has failed a fire assessment. The responsible designer checks the approved information, corrects the authorised source if appropriate and re-exports it. The reviewer reruns the rule and records the outcome against the new file revision. The same workflow can reveal an export-mapping problem even when the authoring model contains the value.

Automate repeatable rules, then review the result

Use a deliberately incomplete test record when setting up a rule: confirm that the check finds the expected failure, and that the corrected record is accepted. If the applicable element count is unexpectedly zero, investigate the scope, classification and export before reporting success. Retain the rule version, applicable count, failed count and unresolved exceptions so that a later reviewer can understand what was actually tested.

buildingSMART’s Information Delivery Specification (IDS) user manual describes requirements in terms of applicability and required information for IFC models. The BCF 3.0 documentation describes exchange of model-related issues between applications. Use the supported project versions and test the exchange with the receiving team; an IDS check and a BCF issue have different purposes.

Download the architectural BIM model-validation checklist (CSV)

The checklist is an original review aid with blank result fields, not a certificate, a vendor assessment or evidence from a completed project. Agree the acceptance criteria before use. Record Pass, Fail or Not tested, with the checked revision, evidence, reviewer and any exception owner.

Connect unresolved findings to the BIM work-package release workflow. Where an attribute is needed for operation, carry its verified identity and evidence into the asset information handover and receiving-system tests.

Use a traceable issue workflow rather than disconnected screenshots

A model viewpoint is most useful when it travels with the issue record. The open BIM Collaboration Format (BCF) supports issue communication around a model location without requiring every participant to work in the same authoring application. Whether the project uses BCF or a proprietary platform, keep a stable issue identifier and an auditable status history.

Suggested statuses are open, assigned, proposed, under review, accepted and verified. Illustrative example: issue CL-001 records a supply duct intersecting a beam in an upcoming work package. The coordination owner assigns the design interface for review; the authorized designers agree a revised route, the model is updated and the check is rerun. Verification records the revised model, drawing and work-package references before release. Do not infer approval from a screenshot or relocate a service without design authorization. If the solution needs a formal variation or instruction, link that approval process.

Create a release gate before procurement and installation

Work backwards from the required site start. Allow time for design resolution, coordination review, fabrication information, procurement, method statements and inspection planning. A model that is geometrically clean but published too late does not prevent rework. The construction manager should flag unresolved high-impact issues before purchase orders or fabrication releases are committed.

Release-gate checklist: confirm the current model and drawing revisions; identify unresolved critical or high-priority interfaces; verify design approval of proposed changes; check supports, tolerances, installation access and maintainability; confirm fabrication and procurement use the accepted information; and record any approved exception with an owner and deadline. An unresolved safety or design interface must not be hidden by changing its status to closed. Sample the affected location with the site team and feed field deviations back into the issue log.

Measure outcomes, not just the number of clashes

Raw clash totals vary with model detail and checking rules, so they are poor stand-alone measures of performance. Track the age of critical issues, the share resolved before release, decision latency and coordination-related site rework. Review trends by work package and location to find recurring process failures.

Treat a falling clash count as useful only when the check scope is stable and field outcomes improve. If the count drops because models are incomplete or checks are disabled, the apparent improvement is misleading.

Control dashboard

Performance metrics for project managers