Multidiscipline coordination breaks down when teams exchange models without agreeing what is current, who owns the federation or who can close an issue.
BIM finds the clash; project governance determines which rule applies and who owns the resolution.
That distinction explains why a well-modelled project can still pay for the same coordination failure on site.
For project leaders, the practical requirement is explicit: every formal exchange needs a named owner, an accepted model state and firm authority.
The Cost Nobody Puts in the Programme
Coordination rework is a cost that large-project programmes rarely isolate. Architecture, structure and MEP can each be correct within their own scope.
The cost appears at the interface, where those decisions meet under different assumptions. At those interfaces, the failure usually appears on site as:
- An opening that misses the structural element it must pass through;
- Two services allocated to the same ceiling or riser zone; or
- An approved change that reaches only part of the delivery team.
Each failure can spread from a model correction into redesign, resequencing, delayed work fronts and site recovery.
That pattern gives context to Australian case research by Peter Love and Heng Li, which reported rework costs of 2.40 to 3.15 per cent of contract value across two construction projects.
In those projects, client changes and errors or omissions in contract documentation were the primary causes.
That leaves management with the central question: if large projects already use BIM and clash detection, why has rework not dropped as far as promised?
Coordination Fails at the Handover, Not in the Model
Coordination fails at handover when issued information has no agreed structure, status or acceptance test.
As a result, a model can be correct for its author and still be unusable as the next discipline’s approved input.
Project teams can use structured BIM consulting to turn the AS ISO 19650 framework into project-specific rules and decision rights.
The framework sets requirements and responsibilities, then carries them through planning, review and exchange.
To make that framework operational, the project must assign authority and make the rules binding. That translation rests on three agreements:
- Naming and classification: Set how zones, levels, systems, revisions and statuses will be labelled. This gives every discipline a common way to identify what it receives.
- Level of information need: Define the geometry and data required for each stage. This keeps each review tied to the decision being made.
- Scheduled exchange points: Set the date, model status, recipient and acceptance test for each formal handover. This keeps work in progress outside the authorised federation.
Three Signals That Coordination Has Already Broken
Coordination has already broken when issues reopen, teams use different model versions or one clash type repeats across zones.
Together, these signals point directly to failed closure authority, version control and design rules.
Issues Reopen After They Are Marked Resolved
Reopened issues mean the project has no agreed test for closure. For instance, one discipline may move an element and mark the issue resolved before the affected team validates clearance, access or downstream drawings.
A reliable closure therefore requires evidence of the change, confirmation against the acceptance criteria and approval from one named verifier.
If any of the three is missing, zombie issues return at the next federation.
Disciplines Are Working From Different Model Versions
Different model versions mean the agreed common data environment (CDE) is not controlling coordination. Local copies age as soon as another team publishes a change.
To keep decisions traceable, each coordination round should record the authorised revision and suitability status, along with the publication time and approved use.
Any bypass then creates an ungoverned second source for project decisions.
The Same Clash Type Recurs Across Zones
Repeated clash types expose an unchanged routing, clearance or spatial-allocation parameter. For example, a duct-to-beam conflict on successive levels points back to the same coordination standard.
The coordination lead should then reset the route hierarchy, zone allocation or clearance parameter. The next clash test can verify that standard across every affected zone.
Where the Federated Model Actually Lives
The federated model lives in a governed review cycle recorded in the agreed CDE. Within that cycle, it becomes an accepted coordination state only when its inputs, status and decision owner are known.
To make that cycle reliable, set four controls before the first federation:
- Federation owner: Name the lead designer, head contractor or information manager responsible for assembling and maintaining it.
- Review cycle: Set when discipline models are published, federated and reviewed.
- Closure authority: Name who verifies an issue and who can give final approval.
- Authoritative platform: Define where approved models, issues and decisions are recorded and which status permits downstream use.
Once those controls are defined, understanding how common data environment platforms differ in practice helps the team match the CDE to its delivery structure.
A design-led project may prioritise model lineage and issue association. A contractor-led project may give more weight to drawings, RFIs, field records and commercial controls.
Whichever platform the project selects, it still needs one governed route for publishing, review and acceptance.
Building the Governance Before the Project Needs It
Build coordination governance before mobilisation using four controls that every discipline can follow. Together, they define the decision, the owner and the condition for acceptance.
| Control | Decide before mobilisation | Project effect |
|---|---|---|
| Information exchange points | Dates, model status, level of information need and acceptance criteria | Keeps work-in-progress models out of formal decisions |
| Responsibility matrix | Model authors, federation owner, interface reviewers and final issue verifier | Removes gaps and disputes over ownership |
| Issue workflow | Status definitions, evidence, due dates, escalation and reopening conditions | Prevents unresolved work from being recorded as closed |
| Model validation gates | Naming, coordinates, completeness, suitability and priority issues | Stops an invalid model state from moving downstream |
These controls need to be in place before the first clash report. Once mobilisation begins, every missing rule becomes a live project decision. The team then has to repair the process while it repairs the design.
What Changes on the Next Project
The next project starts with agreed exchange points, one authorised model state and named decision owners.
With that foundation in place, software records and tests the process that management has already defined.
Clash detection can then expose where discipline decisions meet. When every finding follows one workflow and every closure has one verifier, the project can act on the pattern behind each clash.
The result is a corrected project rule before the same failure reaches another zone or the construction site.