If you already do this for a living: Resolved versus closed. Closing on the owner’s word instead of on the next shared model is the single most common reason issues come back.
- Watch out
- What it costs
- Experienced readers
- Remember
- In BIMpedia
The structural engineer says the beam penetration is fixed, and the coordinator closes the issue. The fix was only in the engineer’s working model, never shared. Two months later the same clash appears on site.
The issue goes to Resolved when the engineer says it is fixed. At the next coordination run, the coordinator checks the new shared model, sees the beam moved, and only then sets it to Closed, noting the model revision as evidence.
Finding problems is the easy part of coordination. The hard part is making sure each one is actually fixed. That is the job of the issue log.
Keep statuses simple
Four statuses are enough for most projects:
- Open — raised and assigned, work has not started.
- In progress — the owner is working on it.
- Resolved — the owner says it is fixed in their working model.
- Closed — the fix has been verified in the next shared model.
The difference between Resolved and Closed matters. Plenty of issues are “fixed” in someone’s WIP model and then reappear because the change was never shared. Only close an issue when you have seen the fix in the federated model.
- 1OpenRaised with an owner and a due date
- 2In progressThe owner is working on it
- 3ResolvedOwner says it is fixed
- 4ClosedVerified in the next shared model
One owner, one date, one place to look
Each issue needs:
- One owner — a discipline or person, not “all”.
- A due date — ideally tied to the next model share or a milestone in the delivery plan.
- A location — level, grid or zone.
- A reference — a clash test viewpoint or a BCF topic, so anyone can jump straight to it in the model.
Carry everything forward
Open issues should never disappear between meetings. Each new meeting starts from the previous issue log, with every issue that is not closed. Keep the original ID and raised date so you can see how long an issue has been around.
Watch the right numbers
The total number of clashes says more about your test settings than about the design. Better signals are:
- open issues over time — they should trend down towards each milestone
- overdue issues — anything past its due date needs attention in the next meeting
- resolved this meeting — evidence the process is working
Key takeaways
- Use a small set of statuses with clear meanings: Open, In progress, Resolved, Closed.
- Resolved means the owner says it is fixed; Closed means it has been verified in a new shared model.
- Every issue has one owner, a due date and a reference to where it can be seen in the model.
- Watch overdue issues and the trend of open issues over time, not just the total count.
Your notesSaved locally
Related tool
Agenda, attendance, issue log, actions and minutes. Roll open issues into the next meeting.
Open Coordination Meeting Pack →