Skip to content
BIMpedia
Chapter 2 · Lesson 2 of 3Topic: Meetings and issues

Running a coordination meeting

A good coordination meeting is short, visual and ends with decisions that have owners and dates.

3 min read3 quiz questions
Skip to the quiz

If you already do this for a living: Model status as an agenda item. Reviewing which revision each discipline shared, before any clash, ends most “that is an old model” arguments in the first five minutes.

  • Watch out
  • What it costs
  • Experienced readers
  • Remember
  • In BIMpedia
Story · Tuesday at ten
How it goes wrong

The coordinator opens the clash software in front of twelve people and scrolls through results. Each clash triggers a debate about whose model is current. After ninety minutes, three issues have been discussed and none has an owner.

How it goes right

The agenda arrived on Monday with the issue log. The meeting opens with model status, then works through nine issues in priority order in the federated model. Forty minutes later each has a decision, an owner and a date, and the minutes go out that afternoon.

Most coordination meetings fail in one of two ways: they become a screen-share of thousands of clashes, or a general discussion that ends without decisions. A simple routine fixes both.

The weekly coordination loop
Weekly coordinationRepeat every cycle until the stage is coordinated
1Share modelsChecked, in the CDE
2FederateShared coordinates
3Run clash testsFrom the matrix
4Group into issuesClash Report Importer
5Coordination meetingDecide, assign, date
6Fix in own modelsEach task team
7Verify and closeIn the next shared model

Before the meeting

Coordination starts a day or two earlier:

  1. Confirm each discipline has shared a checked model in the CDE. Note the revision of each.
  2. Federate the models and run your agreed clash tests.
  3. Group the results into issues and add new ones to the issue log.
  4. Send the agenda and the issue log to attendees, so they arrive prepared.

A fixed agenda

Use the same agenda every week. People know what is coming and the meeting gets faster. A typical order:

  1. Attendance and apologies
  2. Previous minutes and open actions
  3. Model status by discipline — what was shared, what is late
  4. Clash review and issue log, in priority order
  5. Design changes, RFIs and upcoming deliveries
  6. Any other business and next meeting date

Reviewing issues

Go through issues in priority order, in the federated model, not in a spreadsheet. For each one, agree on a decision: who moves, what changes, or whether more information is needed. Record the decision, the owner and the due date while everyone is still in the room. If a decision cannot be made, record what is blocking it and who will unblock it.

Keep an eye on time. If an issue needs a long design discussion, take it offline with the people involved and record that as an action.

After the meeting

Send minutes and the updated issue log within a day. The minutes are the record of decisions; the issue log is the live list of work. The next meeting starts from the issues that are still open — nothing disappears just because a new week has started.

Key takeaways

  • 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.

Your notesSaved in this browser

Related tool

Agenda, attendance, issue log, actions and minutes. Roll open issues into the next meeting.

Open Coordination Meeting Pack →

Check yourself

3 questions · 2 right to complete
  1. 1. What should be done before the meeting starts?
  2. 2. What should every issue discussed have when the meeting ends?
  3. 3. Why start each meeting from the previous one's open items?
0 of 3 answered
PreviousSetting up clash tests that matterNextTracking issues to closure

Discussion