An Open Coordination Item Ages Like Milk

Day 1, an issue is cheap. Two ducts fighting for the same run. A beam passing where a sprinkler main wants to go. Somebody in the model can move it in a few minutes and the job moves on. That is the whole reason to solve it in the model, where the same fix runs about $50, instead of on site, where the same problem costs $5,000 to $50,000. Day 1 is where you want to be.

Day 3, it is not a clash anymore. It is a question. The sheet has been printed, the revision has moved on, and the person who raised it is not sure whether anyone picked it up. Two people are now spending time working out which export is current. Nothing on site has stopped yet, but the clock is running on a decision that should have taken an afternoon.

Day 7, the money starts moving. A crew is on site and cannot install. An unresolved clash sitting behind a whole zone can burn $15K to $50K a week in idle field labour. Not a dramatic number in a boardroom. Very dramatic when it is your crew, your week, and your margin.

That is the aging curve. Cheap on day 1, expensive by day 7, and brutal by day 14 if the same item is still open and now has an RFI on top of it. The problem is almost never that people cannot fix the clash. It is that nobody can prove it is fixed, so it stays open, and open items do not stop work. They just stop it later, when it costs more.

The fix is not a faster meeting. It is a different rule for what closing an issue means. BidLight runs coordination inside Revit and Navisworks, on the model the team already works in, and it gates the close. An item does not close on a status update. It closes when there is a screenshot, a tagged user and the model commit that fixed it.

That one rule changes the shape of the week. Issues stop lingering as maybe-solved. They either have proof or they do not, and everybody can see which.

What a Status Update Costs You

Every coordination meeting has the same 20 minutes in it. Someone reads down the list. A name gets called. The answer is some version of: I think that is done. That is a status update. It is not proof, and everyone in the room knows it.

So what happens next? The item stays open, because nobody wants to close something they cannot see. It goes on the list for next week. Next week, the same 20 minutes, the same item, usually the same answer. Two, three, four weeks on the list. Meanwhile the model has moved on, the export has been superseded twice, and the people who needed the answer have given up asking.

Here is the part that really hurts. Workarounds. A crew that cannot get a clear answer will route around the problem. They will install the duct lower, or stub the pipe and come back, or just avoid the zone. That workaround is never free. It shows up later as rework, a change order, or a section of the job that has to be opened back up.

Now add the version question. Studies of coordination teams put the time lost to working out which model version is current at about 11 hours a week. Eleven hours of people with real jobs, comparing exports and checking emails and scrolling Teams threads. That is not a tooling problem. That is a proof problem wearing a version-control hat.

When closing requires evidence, all of this changes shape. There is no maybe. Either there is a screenshot tied to the element and a commit that shows the fix, or the item is open and the owner knows it. The meeting gets shorter because there is nothing to debate. The same review that used to run 90 minutes takes about 15 minutes because everyone is looking at the same diff instead of arguing about the state of the job.

The status update is not a communication failure. It is a design flaw. Once you stop accepting it as a valid close, the whole loop speeds up.

What the Gate Is, and Why It Holds

A gated issue loop sounds like process language. It is not. It is three concrete things attached to every coordination item, and every one of them is checkable in under a minute.

First, a screenshot. The fix shown, not described. Second, a tagged user. A name that owns the close and can be asked about it. Third, a linked model commit. The exact change in the model that solved the problem, so anyone can open it and see the geometry as it now stands. An issue pinned to the element it concerns, carrying the sheet and the revision that raised it, closing only against those three things.

Why does the gate hold when a weekly list does not? Because it removes the two ways an issue lingers. It removes the maybe-it-is-done close, since you cannot fake a commit. And it removes the I-thought-someone-else-had-it close, because the tagged user is right there next to the item. Ownership is not implied by who raised it. It is explicit and visible.

There is a second-order effect that matters more than the first. When an issue closes with proof, it does not come back. Not from the same clash, anyway. The workaround never gets built, so there is no rework to unpick. The proof sits in the record, so when the question arrives six weeks later from the field or the architect or the owner, someone can answer it in one link instead of a two-day archaeology exercise.

The gate is not about being strict with people. It is about giving people a way to finish. Nobody wants to carry a two-month-old coordination item around in their head. What they want is a way to say it is done and be believed.

What Seven Days to Close Looks Like on a Real Job

The BidLight median issue closes in about 7 days. Not because the team works harder, but because the loop from raise to close has no dead time in it. Here is what a week looks like when the gate is running.

Monday morning, the exports from last week have been versioned and diffed element by element, by category: structural, MEP, envelope, interior. Everything that changed is visible in one place. Issues are raised against the specific elements, pinned where they live in the model, carrying the sheet and the revision that flagged them. No one is spending Monday reconstructing what happened last week.

Tuesday through Thursday, work happens where the work happens. Coordination runs inside Revit and Navisworks, not in a separate portal with its own login and its own stale copy of the model. A coordinator moves the duct, tags the issue, drops the screenshot, links the commit, closes it. Someone else picks up the next one. The clock on each item is short because the path is short.

Friday, the project view shows every open issue against its owner. Not as a reprimand. As a map. Anyone can see what is behind and how behind, while there is still schedule left to move work around. That is the difference between managing a coordination backlog and discovering it three weeks before a milestone.

That last part is the one people underrate. With a weekly list, you find out who is behind when the work has already slipped. With an always-on view plus the 6am digest in everyone's inbox, you find out while the schedule still has room for it. Recovery is a schedule activity. It needs lead time.

And by the following Monday, the median item has been closed and proven. Not parked. Not rolled forward. Closed. If you want a reference point, the same pattern of running a live record inside the tools the team already lives in is what produced 18,000+ hours saved and $12.3M cost saved on the hyperscale programme. That was not heroics. That was the loop doing its job.

The Cost Control Is Not the Report, It Is the Timing

It is tempting to think of coordination savings as a reporting outcome. Something you show the client at the end. That is not where the money is. The money is in when the fix happens, and a gated loop pulls every fix earlier in the timeline.

A clash found in the model costs about $50 to resolve. The same clash found on site runs $5,000 to $50,000. That spread is not a markup. It is the difference between moving geometry in software and moving installed work, with labour, access, sequencing and inspections attached. Every day you shave off the close time is a day closer to the low end of that range.

Then there is the idle labour behind an unresolved clash. A zone that cannot be installed is not just a delayed zone. It is a crew on site with nothing to do, or worse, a crew redirected to work that will need to be undone. That is where $15K to $50K a week goes, quietly, while the item sits open on a list somewhere. Seven days to close versus thirty days to close is not a process metric. It is a line in the job cost.

There is a rework line too. Workarounds built around an open item almost always get torn out. Rework is the expensive, ugly cousin of a clash. It costs the material, the labour twice, and often a change order to defend. A gate that stops the workaround from being built in the first place is worth more than a faster report on how much rework happened.

And then the coordination cost itself. A 15-minute review instead of a 90-minute meeting is one hour and fifteen minutes back, per meeting, for everyone in the room. Multiply that across the coordination team across a project and it is a real number. The 11 hours a week lost to version confusion goes the same way. Not through a productivity push. Through removing the reason to spend the time.

None of this is pricing. Nobody is asking the model to tell you what the job will cost. It is the opposite: make the coordination work land earlier, and the cost control falls out of the job on its own.

What to Change First

You do not need to rebuild your coordination process to get the benefit of a gated loop. Start with the close rule. One sentence: an issue closes when it has a screenshot, a tagged user and the model commit that fixed it. Nothing closes on a status update, not even on Friday at 4:55.

Then get the version question out of the way. If your team is still working out which export is current by hand, that is the first place to look. Every export versioned and diffed element by element, by category, so the answer is one view, not one meeting. That alone tends to give people back a chunk of their week.

Then make ownership visible. A daily 6am digest that tells every owner what they own, and a project view that shows open issues against names. Ownership that is visible early is what lets you recover schedule instead of explaining a slip. Doing it at the end is just documentation of a problem you already had.

The tools matter less than the rule, but the rule is easier to hold when the tools are in the model the team already works in. Coordination inside Revit and Navisworks, issues pinned to the element, the sheet and the revision attached, the close gated against proof. That is the whole idea. It is not complicated. It is just different from the list.

If you want to see how this runs in practice, the plans start at $260 per license per year for Basics and go to $590 for Max, with custom Enterprise pricing above that. And if the coordination work itself is the bottleneck, BidLight does done-for-you BIM work too: execution plans, 4D sequencing, fabrication detailing and spooling.

But start with the close rule. Seven days to close is not a target you chase. It is what falls out when closing an item means something.