Chapter 2 recap
Coordination
The key takeaways from this chapter’s 3 lessons.
Setting up clash tests that matter
- Decide in advance which discipline pairs are tested, with what type, tolerance and priority. Write it down as a clash matrix.
- Choose tolerances that ignore modelling noise but catch real problems.
- Every test needs an owner who is expected to resolve its clashes.
- Group raw clashes into issues before a meeting. People resolve issues, not clash counts.
Running a coordination meeting
- Prepare before the meeting: federate shared models, run tests, group clashes into issues.
- Use a fixed agenda so the meeting becomes a routine, not a debate about what to discuss.
- Review issues in priority order, in the model, and record a decision for each one.
- Send minutes and the updated issue log within a day, and start the next meeting from the open items.
Tracking issues to closure
- 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.