A meeting needs a decision to make
A building information modelling (BIM) coordination meeting should produce decisions that can be implemented and checked. A clash is an apparent overlap between modelled objects; resolving it may require more than moving one object. Reviewing a long clash list without the relevant decision makers can leave the team without an agreed way forward. Frame each item as an engineering or delivery question.
This is our recommended meeting practice, not a substitute for design approval or contractual instructions. The project's common data environment (CDE) procedure should define how meeting decisions are recorded and authorised for use. CDE guidance distinguishes shared review information from authorised use [1].
Prepare the issue before the meeting
Identify the location and source revisions. Show the affected elements and describe why the condition matters: installation sequence, access, ceiling space, an opening requirement or another project constraint. A screenshot helps locate the problem, but should not be the only evidence available to reviewers.
Separate routine modelling corrections from decisions requiring several parties. Send straightforward corrections to the responsible author, with a reviewer and a required recheck before closure. Reserve meeting time for competing constraints that need agreement. Prepare feasible options and identify missing inputs rather than presenting only one discipline's preferred route.
Invite the authority needed for the decision
The modeller can explain the model; the coordinator can explain the interface. Neither role automatically has authority to approve an engineering change. Establish who can accept the proposed route, opening, access arrangement or sequence. If that person cannot attend, agree a decision deadline and escalation route in advance.
Where information is missing, make obtaining it the action. Asking someone to resolve a clash is not useful if the real blocker is an unconfirmed equipment dimension or a pending architectural decision. Assign the information request to an owner and identify which subsequent decision it enables.
Record the outcome in implementable terms
An illustrative decision might retain the primary duct route and require a revised cable tray arrangement, subject to the responsible designers' review of access and support requirements. The record should identify the chosen direction, the affected revision, the remaining engineering check and the parties responsible. It should not simply say agreed.
Give each action a deliverable and a due date aligned with the next review. Link the resulting model or drawing revision to the original issue. Close the action only when the agreed evidence has been checked; a verbal report that it is done is not the same as acceptance of the corrected interface.
Review the decision queue
- Which issues need a decision rather than an authoring correction?
- Are the current reference revisions available?
- Is the engineering or delivery constraint clearly stated?
- Are feasible alternatives and unresolved assumptions visible?
- Is the required decision authority present or assigned?
- Does each outcome identify an owner, deliverable and recheck?
After the meeting, review overdue decisions and repeated issues alongside clash counts. Distinguish a production backlog from missing inputs or an approval delay before choosing the response. A newly raised risk may be useful information rather than evidence of poor performance.
SmartBuild Tech's coordination and advisory support can help structure this decision queue so model review connects to the next engineering and construction action.
References
- UK BIM Framework (2020) Guidance Part C Edition 1 ↗ CDE workflow and information states, sections 1 and 2. UK implementation guidance, not a Singapore project mandate. Accessed 3 October 2026.
Useful insight?
