The textbook clash detection workflow is "set up models, run tests, distribute report." On a real project you have eight consultants on different update cycles, a coordination meeting Wednesday at 10, a BIM Execution Plan that says you'll publish a clash report Friday, and a structural engineer who pushed an unannounced model revision at 11pm Tuesday.
Coordination weeks have a rhythm — federate Monday, triage Tuesday, coordinate Wednesday, chase Thursday, publish Friday — and the coordinators who protect that rhythm get compounding returns from it. This is what the week actually looks like.
Monday: federate and run
8:00–8:30, pull updates. Check the CDE (BIM 360, Trimble Connect, ProjectWise, whatever your project uses) for new model issues since Friday. Download to your local cache. Do not federate yet. Pull everything first so you're working from a consistent snapshot.
8:30–9:00, refresh the federated NWF. Open the coordination NWF, refresh appended models. Save as Project-Coord-WkXX-Mon.nwf. The dated copy is your audit trail when someone asks "what did the model look like Monday?"
9:00–10:00, run the test suite. Each clash test gets re-run individually. Don't "run all tests" and walk away. Watch for tests that suddenly explode in count (usually a sign that a search set caught something it shouldn't, or someone changed a level naming convention).
10:00–11:00, triage new clashes. New = anything not in the test from last Monday. Old + still active = roll forward. Old + no longer geometric = mark closed. On a healthy project, only a small share of Monday's list is genuinely new; if most of the list is new every week, models are churning too much.
By lunch you should have a clean clash list with names, owners, and priorities for the Wednesday meeting. This is the block where automation earns its keep: naming, priority, and owner assignment follow rules, and rules can run themselves. Try it on your own Monday list, free for 14 days.
Tuesday: route and chase
Morning, push the clashes out. Each clash group goes to its owning consultant, ideally through whatever issue tool the project uses. Email is acceptable but doesn't track resolution.
Midday, walk the model. This is the part that gets cut when other work piles up, and it's the most valuable hour of the week. Open the federated model, navigate through complex zones (mech rooms, slab penetrations, equipment pads) and look for future clashes: geometry that's about to overlap as the design progresses. Document these as proactive flags, not active clashes.
Afternoon, chase last week's open items. Any clash that's been "Active" for more than 7 days needs a follow-up. Half the time the consultant has resolved it and forgot to update; the other half they're stuck and need a coordination call.
Wednesday: the meeting
Pre-meeting (15 min before). Re-run any clash test where the owning consultant claimed to have resolved an item. If they did, the clash is gone and you can announce closures at the top of the meeting. Fastest way to build trust.
The meeting itself. Filter to the new + still-active clashes since last meeting. Walk through them in order, by zone. Each one: name, viewpoint, owner, target date. Don't dive into resolution discussions in the meeting unless the owner is in the room and the resolution is non-obvious. Otherwise it goes on a side track.
The minutes problem. The traditional failure mode is that everything agreed in the room lives in the coordinator's head until they type it up — and the half-life of "what we agreed" is about an hour. This is what live coordination sessions exist for: start a session before the meeting, and every clash status, priority, owner, and due-date change is recorded automatically as you make it, with decisions and action items captured against owners as they happen. End the session and the minutes — PDF included — are generated from what was actually recorded, not from memory.
Post-meeting (within 30 min). If you're keeping minutes manually: update statuses, add meeting notes to each clash group, push the updated tracker out. Immediately. Memory fades fast.
Thursday: deep work
This is the day you actually have time to think. Use it for:
- Search set audits. One discipline per week. Open every search set for that discipline and verify it still catches what it should. Naming changes in the source model break search sets silently.
- Clash test parameter review. Are tolerances still right for the project stage? Should any tests be split or merged?
- Documentation. Update the BEP, your coordination procedures doc, anything that's drifted from current practice.
- Onboarding next week's items. If you know an MEP consultant is publishing Friday, line up the test you'll need to re-run Monday.
The temptation Thursday is to fill it with reactive work. Resist. The proactive day is where coordination quality comes from.
Friday: publish and snapshot
Morning, final re-runs. Anything claimed resolved this week gets verified. Closures get logged.
Midday, issue the report. If your BEP requires a weekly clash report, generate and publish it. Keep the format consistent week-to-week. Your stakeholders are pattern-matching on the layout, not reading the prose.
Afternoon, snapshot. Save the week's federated NWF to a "weekly archives" folder with the date. If a question comes up in three months ("when did this clash first appear?"), the snapshots are how you answer.
Where the time actually goes
Run this week honestly and then look at where the hours went. For most coordinators the ranking looks like this:
- Triage — naming, grouping, routing, status updates. The largest single block, every week.
- Chasing open items — follow-ups, provisional closures, "did you actually fix it?"
- Coordination meetings — plus the pre-runs and the minutes.
- Walking the model proactively — the most valuable hour, and the first one that gets cut.
- Documentation, snapshots, audits — the system maintenance that keeps everything else honest.
The uncomfortable part: the biggest block is also the most mechanical. Naming and routing follow rules you already know — which means they can be automated, and the recovered time can move up this list into the proactive walk-throughs and audits, the work that actually moves project quality. That trade is the whole argument for coordination tooling built around this workflow.
What breaks the rhythm
Three things, in order of frequency:
- An out-of-cycle model push. Mitigate by setting a project-wide rule: model updates land by Friday EOD or they wait until the following week.
- A consultant who doesn't update statuses. Mitigate by making your tracker the source of truth, not theirs. If they say "resolved" verbally, you mark it resolved provisionally and re-test Friday.
- Tests that drift in scope. A search set that quietly starts catching geometry it shouldn't will explode your clash count overnight. Your Thursday audit catches this.
Where to start improving
If you don't currently have a fixed weekly cadence, that's the highest-leverage change. Pick the days, hold to them, communicate them. Everything else builds on that rhythm.
If you have the cadence but triage is eating your week, the next step is automation: search sets in place of selection sets, AI-assisted naming, rule-based routing, and coordination sessions that write their own minutes. The mechanics are the lowest-value part of the job; offload them.