Model coordination meetings: converting clashes into decisions
Admin · 22 October 2026
Illustrative image. Photo by Cherrydeck on Unsplash. Unsplash License.
A clash report can contain hundreds of observations without telling the project which decisions matter next. Some observations may reflect modelling conventions, some may be duplicates and others may expose a consequential interface. The coordination meeting should turn that raw output into assessed issues, accountable actions and revised information. Its value is the quality of the resolution process, rather than the volume of clashes displayed or closed.
For design managers and digital coordination leads, the challenge is to connect the model review with the people responsible for design and delivery. Software can help identify potential conflicts, but it does not automatically determine the technical response or authorise a change. The meeting needs clear inputs, a defined purpose and a route for decisions that sit outside the participants’ authority.
Establish the information being reviewed
Record the models, revisions and status used in the coordination set. Confirm the project reference arrangement and any known limitations. Participants should know whether the review contains current information and which areas remain incomplete. A visually detailed federated view can conceal an outdated contribution, so the issue record needs to preserve its actual basis.
Define the review purpose. A check supporting an early spatial decision differs from a review intended to inform a package release. Identify the work areas and interfaces included, together with exclusions. This prevents the absence of a reported issue being interpreted as evidence that every aspect of the design has been assessed and found suitable.
Prepare the issues before the meeting
Review automated findings and group observations that relate to the same underlying question. Remove or classify irrelevant results through the agreed process, keeping appropriate traceability. The aim is to bring participants a manageable set of meaningful issues. A meeting spent navigating unfiltered output gives technical reviewers little time to consider consequences and alternatives.
For each significant issue, provide the location, affected systems, information references and a clear question. Explain why a decision is needed now. Link it to the next design or procurement commitment where relevant. This allows the correct people to prepare and helps the meeting distinguish urgent release constraints from matters that can be developed at a later stage.
Invite the people who can resolve the interface
Identify the designers, specialists and other contributors needed for the selected issues. An attendee may be able to navigate a model without authority or expertise to alter the design. Make that distinction explicit. Where an operational requirement is involved, the client may need to contribute; where the question is technical, it should reach the relevant responsible specialists.
Give participants enough information and preparation time under the project’s arrangements. If the issue cannot be decided because a necessary input is missing, use the meeting to define that input and assign an owner. Do not force an apparent resolution simply to reduce the open issue count. The record should reflect the decision actually supported by the evidence.
Discuss function as well as geometry
A geometric overlap is a prompt for assessment, not a complete explanation of the problem. Ask what the affected elements do and which requirements constrain the response. Moving an object may remove the visible intersection while creating another issue concerning operation, maintenance or a connected system. The appropriate technical teams should assess those implications before accepting the change.
Consider a hypothetical services route crossing an area allocated for access to equipment. The model may show no hard overlap between the objects, yet the intended operation could still be compromised. The coordination process should identify the requirement and obtain the relevant assessment. This illustrates why a clash-free model should not be treated as proof that every functional interface is resolved.
Assign one clear resolution owner
Each issue needs a person responsible for coordinating the response, with contributors identified separately. That owner does not automatically inherit every design responsibility. Their role is to bring the required information and decisions together under the project’s agreed arrangements. Avoid assigning an action vaguely to several organisations when none is responsible for moving it forward.
State the output required to close the issue. It may involve a revised detail, a recorded technical decision or confirmation of a requirement through an authorised route. Set a date linked to the affected activity. If the owner cannot provide the response by then, the team needs to assess the consequence rather than repeatedly change the date without explanation.
Record the decision and its conditions
Capture the option selected, the information reviewed and any conditions attached to proceeding. Distinguish a proposed direction from an approved technical solution or contractual instruction. The applicable appointments and governance determine who can authorise each commitment. A note in a model issue platform should not casually imply broader approval than the meeting actually obtained.
Where the issue involves an assumption, preserve it in the record and identify how it will be verified. An assumption should not disappear when someone changes a status field to resolved. If the project proceeds conditionally, the receiving team needs to understand the boundary of that decision and the remaining action before it relies on the information.
Update the connected information
A model change may require updates to drawings, schedules or specifications used elsewhere. Identify those consequences and assign the work. Closing the original observation is not sufficient if another package continues to use an inconsistent output. The coordination lead should track the required updates through the relevant information process without replacing the authors’ responsibilities for their content.
The APM overview of configuration management provides general context for knowing the current information position and tracing changes. Applied here, the practical requirement is to establish which revised outputs reflect the coordination decision and which information set has subsequently been checked together.
Verify closure with evidence
Agree how closure will be assessed under the project’s procedures. A statement that the author has moved an object may not demonstrate that the interface is resolved. The required check should reflect the original question and the responsibilities involved. Record the evidence or reference that supports closure so that a later reviewer can understand the outcome.
Use different statuses where they help distinguish response, revision and verification. The exact labels should fit the agreed workflow. Their meaning matters more than the number of categories. Participants should be able to tell whether an issue is awaiting a decision, being implemented or ready for a defined release without interpreting an ambiguous percentage or colour.
Report consequences rather than counts alone
Issue counts can help administer the process, but they are a weak measure of design readiness by themselves. A small number of unresolved interfaces can control a major release. Report the significant constraints, required decisions and dates alongside any volume measures. This gives project leadership a practical view of where intervention or additional information is needed.
Review recurring causes after major releases. Repeated issues may indicate late inputs, unclear responsibilities or a modelling convention that needs clarification. Address the cause with the relevant team rather than simply running another clash test. A useful coordination meeting leaves people with a shared account of what matters, who will resolve it and how the resulting decision will reach every affected output.
Also review issues that reopen after apparent closure. Identify whether the original evidence was incomplete, a later change altered the interface or the closure criteria were unclear. These causes require different responses. Recording them helps the team improve the review process and prevents the same observation circulating through repeated meetings without a durable resolution or a clear explanation of why its status changed.
Check that issue references remain accessible when information is archived. A closure note linked only to a temporary viewing session may lose its meaning later. Retain the location and relevant references in the agreed project record.
