How to Run BIM Coordination Meetings That Actually Move Projects Forward

Most BIM coordination meetings fail in a quiet, expensive way. Twelve people join a call, someone shares a screen, a clash report scrolls past, and an hour later everyone leaves with a vague sense that “MEP will sort it out.” Nothing was decided. Nothing was assigned. The same clashes come back the next week wearing slightly different colours.

I have run and sat through hundreds of these. The good ones share a shape, and the bad ones share the same three or four failures. This is a practitioner’s guide to running the meeting so that it produces decisions, owners, and due dates, and so that the model on Friday is measurably better than the model on Monday.

What the coordination meeting is actually for

A coordination meeting is not a status update. It is a decision-making session held in front of a federated model. If your meeting can be replaced by a shared spreadsheet and a read-through, you are holding a status update and calling it coordination.

The meeting exists to do three things that email and issue trackers cannot do well on their own:

1. Resolve the clashes that need a human judgement call. A duct and a beam occupy the same space. Does the duct drop, does the beam get a penetration, or does the room layout change? That is a conversation between disciplines, not a ticket.
2. Make trade-off decisions with everyone in the room. Coordination is rarely “who is right.” It is “which move costs the project least.” Those calls need the structural, MEP, and architectural leads present at the same time.
3. Assign ownership with a deadline. Every unresolved item leaves the meeting with a name and a date attached, or it did not really get discussed.

Hold that definition in your head and most of the rest follows.

Set the cadence before you set the first invite

The single most common mistake is running coordination at the wrong frequency for the project phase. Too often and the model has not changed enough to be worth reviewing. Too rarely and clashes pile up faster than the team can clear them.

Match the rhythm to the phase:

Project phase	Meeting frequency	Focus
Early design / concept	Every 2 weeks	Spatial coordination, major systems routing, floor-to-floor heights
Design development	Weekly	Discipline clashes, shaft and riser coordination, ceiling void conflicts
Pre-construction / tender	Weekly	Constructability, sequencing clashes, penetrations sign-off
Construction / delivery	Weekly, sometimes twice weekly	Site-driven changes, RFIs against the model, as-built alignment

A weekly slot is the default for a reason. It is short enough that no single discipline can drift far off the federated model, and long enough that each team can actually resolve what was assigned the week before. Keep the same day and time every week. Predictability is what lets a busy structural lead protect the slot.

Decide who is in the room, and who is not

An overcrowded coordination call is as useless as an empty one. Every extra person who does not own a model dilutes the decision-making and lengthens the meeting.

The core attendees:

• BIM coordinator or manager who chairs, drives the model, and owns the issue log.
• Discipline leads for architecture, structure, and MEP. These are the people who can commit to a change, not just note it down.
• Anyone whose model is on the critical path this week. Facade, vertical transportation, or a specialist subcontractor when their scope is live.

Keep it to the people who can make or accept a decision. Observers, junior modellers, and stakeholders who want a general update should get the exported report and the minutes, not a seat in the working session. If a design manager needs the wider picture, run a separate, shorter review off the same issue log.

Prepare the model before anyone joins

The meeting is where you decide. The preparation is where you find. If you are running the clash detection live while ten people watch a progress bar, you have already lost twenty minutes.

Your pre-meeting checklist:

• Pull the latest models from every discipline into a fresh federated model. If a discipline did not publish, note it. A stale model is a decision made on bad information.
• Run the clash tests in Navisworks, Solibri, or your platform of choice, using saved, named clash rules so the tests are identical week to week.
• Group and filter the results. A raw report of 4,000 clashes is noise. Group by system pair (structure vs MEP, MEP vs MEP), strip out the tolerance-level duplicates, and reduce it to the handful of real conflicts worth a human conversation.
• Pre-assign the obvious ones. If a clash clearly belongs to one discipline, tag it before the meeting so the room can confirm rather than debate.
• Build the viewpoints. Save a camera view per issue so you can jump straight to it. Hunting for a clash in 3D while everyone waits is the fastest way to lose the room.

Done well, this preparation turns a two-hour meeting into a forty-minute one.

An agenda that decides instead of drifts

A coordination meeting without a time-boxed agenda expands to fill whatever time you give it. Here is a structure that keeps a weekly delivery-phase meeting to under an hour:

Time	Item	Outcome
0-5 min	Model status and publish check	Confirm which models are current
5-10 min	Review last week’s assigned issues	Close resolved, escalate stuck ones
10-40 min	Work the priority clashes live in the model	A decision and an owner per issue
40-50 min	New issues raised by the team	Logged, assigned, dated
50-55 min	Actions recap and confirm owners	Everyone hears their own list read back
55-60 min	Buffer	Absorb overruns

Two things make this work. First, the review of last week’s items comes before new work, so nothing quietly falls off the list. Second, the recap at the end is read aloud from the issue log so every owner hears their assignment confirmed in front of the group. Silent agreement in a chat window is not commitment.

Run decisions off the model, not off screenshots

This is the line between real coordination and theatre. When a clash comes up, navigate to it live in the federated model, orbit around it, and let the disciplines see the actual geometry and the space they have to work with. Screenshots flatten the problem and hide the context that usually holds the answer.

Working in the live model lets you test the fix in the room. If the proposal is “drop the duct 150mm,” you can check on the spot whether that busts the ceiling void or clashes with the sprinkler main below. Half of coordination decisions are settled the moment everyone can see the same 3D space at the same time. That is the entire reason the meeting exists rather than a thread of emails.

Keep the navigation calm and deliberate. A coordinator who flies through the model at speed loses everyone. Move to the saved viewpoint, pause, describe the conflict in one sentence, and ask the disciplines the trade-off question.

Track every issue to closure

A decision that is not logged did not happen. The heart of a working coordination process is an issue that moves through clear states and never gets lost.

Give every issue a small, honest lifecycle:

1. Open. Raised, described, and assigned to a discipline with a due date.
2. In progress. The owning discipline is working the fix in their model.
3. Ready for review. The fix is published and waiting to be checked in the next federated model.
4. Closed. Verified against the current model, not against a promise.

The discipline that owns an issue does not get to close it. The coordinator closes it after confirming the fix in the updated federated model. That single rule stops the most common form of coordination rot, where issues are marked “resolved” because someone intended to fix them, not because they were fixed.

Use the open standard where you can. BCF (BIM Collaboration Format) lets you carry an issue, its viewpoint, its comments, and its status between different tools and different companies without losing the thread. It is the difference between “I emailed you about a clash near grid C4” and handing the other team the exact camera view and the element in question.

The issue tracker is the meeting’s long-term memory

The meeting is an hour. The issue tracker is the record that outlives it. Whether you run Navisworks with an exported log, Autodesk Construction Cloud, Revizto, or BIMcollab, the tracker is where accountability lives between sessions.

A tracker worth trusting has, for every issue:

• A stable ID that both teams reference in email, RFIs, and the meeting.
• The saved viewpoint, so anyone can see exactly what is being discussed.
• An owner, a status, and a due date that are all current.
• A short comment trail showing what was decided and why.

When the tracker is the shared source of truth, the meeting gets shorter every week, because nobody has to re-explain history. New team members can read the log and understand a conflict without a fifteen-minute recap. And when a dispute lands months later about who was told what, the record settles it in seconds.

Common mistakes that wreck coordination meetings

I see the same failures on almost every troubled project. Watch for these:

• Reviewing raw clash counts. Presenting 3,000 clashes tells the room nothing except that the model is complex. Group, filter, and bring the twenty that matter.
• No owner, no date. “The team will look at it” is not an assignment. Every discussed item needs one name and one deadline.
• Coordinating stale models. If a discipline has not published since last week, coordinating their scope is guesswork. Enforce a publish deadline the day before the meeting.
• The coordinator solving everything live. Your job is to drive the model and force the decision, not to redesign the ceiling on the fly. Assign it and move on.
• Letting disciplines close their own issues. Verification belongs to the coordinator against the current federated model. Self-closing is how “resolved” issues reappear.
• No preparation. Running clash tests live, hunting for viewpoints, and waiting on model downloads burns the goodwill of everyone who showed up.
• Turning it into a status meeting. If nobody is looking at a 3D model and making a call, you are not coordinating.

Metrics that tell you the meeting is working

You do not need a dashboard, but a few numbers tell you honestly whether coordination is improving or just happening.

• Open issue count trend. In a healthy project it rises during design development, then falls steadily toward delivery. A flat line that never drops means issues are being logged but not closed.
• Average time to closure. How long an issue sits between Open and Closed. If this number is growing, the team is falling behind the model.
• Reopened issues. Issues closed and then reopened point straight at weak verification. A near-zero reopen rate means closure actually means closure.
• Clashes surviving to site. The hard measure. Every conflict that reaches the field as an RFI is one the coordination process missed. Track it and the meeting earns its keep.

Report these in the first five minutes occasionally. Nothing focuses a room like seeing the open-issue line finally start to fall.

Best practices, in order of impact

1. Prepare the federated model and the priority issues before the invite. The single biggest lever on meeting quality.
2. Keep the room to decision-makers. One lead per live discipline, plus the coordinator.
3. Time-box the agenda and review last week first. Nothing falls off the list.
4. Make every decision in the live 3D model. No screenshots for anything spatial.
5. Assign an owner and a date to every open item, out loud, at the end.
6. Use BCF and a shared tracker as the source of truth. The tracker outlives the meeting.
7. Let only the coordinator close an issue, and only against the current model.
8. Watch the open-issue trend and time-to-closure. Manage the numbers, not the vibe.

Bringing it together

A coordination meeting that works is not about better software or a slicker clash report. It is a discipline: prepare the model, bring the right people, decide in front of the geometry, and track every call to closure. Do that every week and the meeting becomes the quiet engine that keeps a project’s models honest and its site free of avoidable rework.

If you want to build the full workflow behind these meetings, from setting up clash tests to running federated coordination end to end, the coordination and Revit tracks at Archgyan Academy walk through the real process, taught by a working BIM coordinator. Learn the moves once, and every meeting you run afterwards gets shorter and sharper.