The Trouble With Looking Only at What Is Drawn

For too long, coordination has been treated as a pass you do once the drawings look complete. Check the sheets, run a meeting, sign off. The assumption is that if everything on the sheet is correct, the job will build the way it is drawn.

It rarely does. Designs evolve. Site conditions surprise people. Trades collide in places no one expected, and they collide with alarming regularity. A ship captain with a perfect inventory still gets caught by weather. A model with every element in place still hides the zone where three trades are fighting over the same ceiling void.

The cost of that is not small. A clash caught in the model costs about $50 to fix. The same clash found in the field costs $5,000 to $50,000. And an unresolved one can burn $15K to $50K a week in idle field labour while crews wait for an answer.

The problem is not a lack of awareness. Everyone knows coordination risk exists. The problem is that it is hard to see where it concentrates. Coordinators are skilled professionals, but they are often left with a gut feeling about which zone will cause trouble. A gut feeling does not survive a schedule squeeze.

Why a Meeting Is Not Enough

A coordination meeting works from memory and from whatever someone prepared the night before. It covers the loudest problems. It rarely covers the quiet zone that changed three times in two weeks, because nobody was watching it.

A record does not forget. When every publish is a snapshot, the history of a zone is there: what was in it, who changed it and when. You can walk into the meeting with the question already answered, and the 90 minutes shrink to the decisions that need people in a room.

Seeing Where the Risk Sits

What if you could stop guessing and read the record that the model already keeps? That is the shift a model-based platform makes possible. BidLight tracks every model change and every clash or issue between revisions, pinned to the elements they concern. When ductwork runs into a structural beam, the issue sits on those elements, with the sheet and the revision it came from.

Take a large commercial building. Compare any two revisions element by element and you can see, category by category (structural, MEP, envelope, interior), where the design keeps moving. Then look at where open issues cluster. The zones where MEP, structural and architectural work intersect show up as the places that keep changing and keep collecting issues.

This is not about a generic "high complexity" label on a floor. It is about pinpointing where the risk sits. Say plumbing, HVAC and fire suppression all meet in one ceiling void. In a normal workflow, that zone gets a note in a meeting. With BidLight, you see the specific elements involved, the issues pinned to them, who owns each one, and how often they changed between revisions.

That gives you a reason to act. You can bring the three trades together on that void before the first crew shows up, instead of after the first clash is found on site.

This also changes the coordinator's role. You stop reporting what is drawn and start steering the team toward the places that will hurt. You are no longer the person who records problems after they happen. You are the person who saw them coming in the revision history.

Putting It Into Your Workflow

Adopting this is not about learning new modelling software. BidLight runs inside Revit and Navisworks and publishes straight from the model, so your team works where it already works. Each publish becomes a versioned snapshot with its own files, author and milestone.

From there, the routine is short:

• Compare the latest revision to the last one, by category.
• Find the zones that keep changing.
• Pin an issue to each element in conflict and tag the owner.
• Let the 6am digest tell each owner what they hold, every morning.

Four steps, and none of them needs a new meeting. The point is that the work moves from memory to the model. The zone that keeps changing is visible on day one, not on the day the first crew stalls. And because every issue carries its sheet and revision, the person picking it up does not have to ask where it came from.

Once the issues exist, they need to close properly. An issue closes only with a screenshot, a tagged user and the model commit that fixed it. So when you tell the GC that the OR suite ceiling is resolved, you can show them the proof. That kind of transparency builds trust far faster than a status line in a meeting.

The project view then shows who is behind while there is still schedule left to move work. You do not wait for a slip to reach the site. A clash that sits 47 days can cost $28,000 in idle field labour. A clash someone owns by Tuesday costs a fraction of that.

Ultimately, the benefit is that you stop competing with surprises. You get a clear picture of where the job can go wrong, and a named person on each risk. Projects land on schedule and on budget not because nothing went wrong, but because what went wrong was seen in the model, owned and closed before the field paid for it.