An agenda does not guarantee coordination

I am writing this from a concrete experience, not a generalisation. I took part in a complex project, with a BIM team and BIM coordination already assigned, where meetings were held regularly. There was a call, there were attendees, there was a list of topics. And yet information about changes and decisions did not always turn into traceable agreements. In the meetings I experienced, matters moved through without sequence or coherence from one item to the next.

In this case, the problem was not the absence of meetings. It was the structure of the items discussed in them.

The concrete fact: "progress review of the electrical model on level 2"

After I raised my concern about the way those meetings were being run, written agendas began to be sent out. A step forward — but one of the items, as it arrived, read literally: "progress review of the electrical model on level 2."

That single line was meant to cover the review of an entire engineering discipline, inside a meeting of roughly 30 minutes, without first defining which part of the model would be reviewed, against which criteria, or with the guaranteed presence of someone with sufficient technical competence to validate it. It was not a lack of goodwill in the room. What was missing was the information that makes a real decision possible within the time available.

The outcome is not hard to imagine: a meeting that can consume its entire time without producing a valid technical review. Not a rejected review, nor a poorly done one — a review that, structurally, could not happen with what that agenda item carried.

This case does not include costs, quantified delays, or construction errors attributable to this specific episode, and I am not going to invent them here. What I can describe with precision, because I lived it, is the pattern: missing information, an unresolved decision, unassigned responsibility.

What was missing was not willingness — it was structure

Looking at what that agenda item lacked, the list is specific, not generic:

• The concrete changes to be analysed had not been defined beforehand.
• It was not clear which current information the model should be checked against.
• The engineering criteria that would determine whether the progress was acceptable had not been set.
• The exact decision the meeting needed to make had not been formulated.
• The presence of someone with the specific technical competence to validate that part of the model had not been confirmed.
• No one had been assigned to close the item, with a date and a closure criterion.

Members of the BIM team and BIM coordination were present, but that did not guarantee the technical competence needed to validate each matter. What did not exist was clear direction: no one was unambiguously assigned to prepare, evaluate, decide, and close each item.

It's worth saying carefully: the above describes a mechanism I observed in this specific case, one I recognize as a recurring risk in technical coordination practice — not a claim that every meeting or every project delay necessarily follows this same sequence.

The method: eight elements per agenda item

This experience yields a lesson I apply beyond this one case: an agenda does not coordinate on its own. It coordinates when every item it contains is built to produce a decision, not merely to occupy a slot on the order of business.

An agenda item designed to lead to a decision needs eight elements:

1. Context — what situation gave rise to this item, and why it is being brought to this specific meeting.
2. Input information — what data, models, or current documents must be available before discussion.
3. Decision required — exactly what needs to be decided, framed as a concrete question or alternative, not as an open topic.
4. Technically competent participants — who, by role and specific knowledge, can evaluate and decide on this particular item.
5. Owner — who is responsible for the item's closure, beyond whoever speaks at the meeting.
6. Date — by when the decision must be closed, not merely when the meeting takes place.
7. Expected evidence — what proof or record will confirm that the decision was made on sufficient grounds.
8. Closure criterion — what condition marks the item as resolved and not to be reopened without new information.

"Progress review of the electrical model on level 2" did not make explicit the elements needed to prepare a technical decision. As framed, it did not operate as an agenda item: it operated as a title.

From the agenda to a register that sustains coordination

This connects to a broader question: what happens to everything a coordination meeting identifies — a pending matter, an observed condition, an unresolved decision — once the meeting ends? If that information is not recorded in a way that can be traced, the pattern repeats: the next meeting tries once again, from memory, to resolve what had already been discussed before.

The SORA Technical Issue Register exists for that function: turning a matter detected — in a meeting, an email, or a field report — into a record with a unique identity, an owner, a target date, verification evidence, and a closure criterion. It does not replace the discipline of building each agenda item well; it gives continuity to what that discipline produces, from detection through to closure.

Next step

If this experience resembles something you have lived through in your own project, the first step is not a new tool: it is applying the eight elements to the next agenda you draft. The Technical Issue Register is the following step, so that what that agenda produces is not lost between one meeting and the next.

---

Project, client, company, name, and location details have been deliberately omitted: what is described here is a real technical coordination pattern, presented without any information that would identify the case.