Design drift is where schedule goes to die. BidLight compares every export element by element, so a 3-inch move reaches its owner in minutes instead of surfacing on site.

Design Moved 3 Inches? Did the Team Hear About It?

The Three-Inch Problem Nobody Puts on a Change Order

Design drift is the slow accumulation of small moves that never get flagged to the people who build them. The corridor shifts three inches to clear a duct. A door swings the other way because the casework got deeper. The architect nudges a demising wall so the tenant layout matches the leasing plan. Each move looks free at the moment it happens. None of them are.

Here is what happens downstream. The model updates in Revit. The markup the trades are working from does not, because it was saved eight weeks ago. The coordination package went out against that markup. So the sheet you hand over matches a design that no longer exists. You are coordinating a building that stopped being real the moment the wall moved.

A Revit model on a monitor shows a duct shifted 3 inches from its old position, beside an eight-week-old calendar and an outdated marked-up coordination sheet t

Most firms handle this by waiting. They wait until the next design milestone, then rebuild the comparison, then reissue, then hope nothing moved again in the meantime. That wait has a cost. You lose the ability to tell the trades what the change means while the change is still cheap to reverse. By the time you have the answer, the drywall is hung and every option has closed.

An isometric floor plan with one interior wall highlighted in orange, shifted 3 inches from its dashed original position, beside a clock and an out-of-date markup sheet.
The honest version is that your coordination record and your design live in two different places. One is a live model that changes every day. The other is a static file that changes when someone finds the time. The gap between them is not a process problem you can hire your way out of. It is a structural problem, and it will keep producing surprises until you close it.

So the question at the top of this article is not rhetorical. Your design moved three inches. Did the team hear about it? If the answer takes more than a few minutes to establish, you already know which of the two documents is lying to you.

Why Markups Fall Behind Models, Every Single Time

A markup is a snapshot. A model is a motion picture. You cannot reconcile a photograph with a film and expect them to stay aligned for long. That is the entire reason design drift creates hidden surprises in the field, and it is why chasing scattered updates eats your week.

A static marked-up paper drawing with a red revision cloud on the left and a film strip of a duct shifting frame by frame on the right, joined by a "3 in" gap m

The mechanics are simple. Someone exports a view from Revit. They mark it up in a PDF. They send it around. That artifact becomes the picture everyone trusts. The moment the model changes, the artifact is stale, but it still looks authoritative. Nobody stamps a PDF with an expiration date, so it keeps getting forwarded, quoted and defended. Somewhere there are 47 versions of the same markup, and nobody is sure which is current.

An isometric building model with a wall shifted 3 inches feeds a stack of markup sheets, which produces a version list cracked by an orange line.
Redoing comparisons is the tax you pay for this. A coordinator spends hours, sometimes days, redoing what they already did once. They are not solving clashes or talking to trades or finding a smarter sequence. They are working out which model version is current, and that is 11 hours a week of work that will be stale again within days. That is the real cost of a static markup, and it compounds every time the design moves.

This is where most coordination tools disappoint. They treat the model as an import, a one-time feed into a separate portal. That solves yesterday's problem. BidLight treats the model as the source of truth and keeps the record riding on it continuously. One live record of the project inside Revit and Navisworks. Publish the model and you get a versioned snapshot with its own files, author and milestone. Change the design and the next publish shows what moved, because there is no second document to fall out of sync.

What a Live Record Looks Like Day to Day

Picture a Tuesday morning review. The architect has moved a corridor wall three inches and shifted two door locations to match. In most firms, that triggers a note, a follow-up and a comparison scheduled for whenever the coordinator has a free afternoon. In BidLight, it triggers a list of changed elements.

Isometric floor plan with a corridor wall nudged three inches and two doors shifted in orange, linked to a review card showing both changes checked off.

You publish the updated model and compare it to the last one. The comparison is element by element, grouped by structural, MEP, envelope and interior, so the wall, the doors and the ceiling above them are already listed before you look. What used to take a 90-minute meeting now takes about 15 minutes, and the 15 minutes are spent reviewing, not hunting.

An isometric building model with a shifted-wall arrow feeds a comparison checklist with changed elements grouped by category and an orange marker on the wall.
Here is the part that changes how you run the coordination meeting. When the GC asks what the three-inch move touches, you answer in the room. Not next week. Not after a markup refresh. You answer while the decision is still open, while moving the wall back is still cheaper than moving the duct. A clash caught in the model costs about $50. The same clash found in the field costs $5,000 to $50,000.

The same record follows the project through Navisworks. You are not maintaining a separate tracking file that shadows the coordination model. There is one record, and it is the same record everyone else is working from. If you have ever watched a coordination session produce a clash resolution that quietly changed what another trade had drawn, you already understand why that matters. Clash resolved, owner tagged, nobody has to remember to tell the next trade.

The Accountability Nobody Talks About Because It Sounds Too Simple

The simplest change is the one that moves the most. Every issue is pinned to the element it concerns and tagged to a person. The daily 6am digest tells each person what they own. The project view shows who is behind while there is still schedule to move work. That is not magic and it is not a sales tactic. It is what happens when you stop coordinating from stale markups and start coordinating from the model as it stands today.

Think about why coordination slips. Sometimes it is workload. Often it is visibility. A GC reads two status reports and one of them is clearly grounded in the current model, with issues that map cleanly to what they see. The other looks assembled from memory. Both could be equally diligent. Only one looks defensible, and defensible coordination keeps the schedule.

A general contractor in a hard hat compares two status reports, one with a clear model view and numbered clash markers, the other a blank placeholder with vague

A building plan with numbered markers linked by lines to the ticked issue list beside it, while a second, vague status report with a question mark sits faded.
There is also the matter of closure. A closed issue means something here: it closes only with a screenshot, a tagged user and the model commit that fixed it. So a three-inch problem that is marked solved has proof behind it, and the same problem does not come back on site.

And then there is the effect over a project. On the hyperscale programme, BidLight helped save 18,000+ hours and resolve 8,900+ issues. Those hours come out of rework and the endless reconciliation between what the model says and what the markup says. Put them back into solving the next clash, or simply going home at a reasonable hour, and the schedule improvement stops looking surprising.

Turning Coordination Into a Visible Service

Most firms give away coordination. A client asks what a design change touches and someone scrambles to produce an answer for free, hoping it buys goodwill that turns into a contract later. That is a bad trade, and it gets worse the more times the design moves.

When the record rides on the model, answering stops being a scramble. You can compare a concept in minutes, then compare again every time the design shifts, and each refresh costs almost nothing. That changes the economics of the service entirely. What used to be an unbilled favor becomes something you can scope, schedule and bill.

Isometric building model on a platform with a window shifted slightly out of place, flanked by a model-view card and a version-comparison bar card linked by a r

An isometric building model with one block shifted from its dashed original position, linked to a growing list of closed issues, with a clock and refresh arrows showing speed.
Clients value this because the alternative is worse. They want certainty during design, when decisions are still reversible and the schedule is still movable. The three-inch question stops being a source of anxiety and starts being a decision they can make with the changed elements in front of them. Firms that offer this get pulled into projects earlier.

Beyond the software, BidLight also does done-for-you BIM work: execution plans, 4D sequencing, fabrication detailing and spooling. Some firms want the capability without the hiring. Others want the tool in their own team's hands. Both are legitimate, and the pitch does not change either way. Stop chasing scattered updates. Close issues with proof. Know who is behind while there is still time.

The Practical Case for One Record

If you only remember one thing about BidLight, remember this. It keeps one live record of the project inside Revit and Navisworks, with every export versioned and every change diffed. Everything else, the pinned issues, the 6am digest, the plans that run from Basics at $260 per licence per year to Max at $590, is downstream of that single idea.

That is why the design drift problem stops being a problem. There is no second document to go stale. There is no reconciliation meeting between the model and the markup, because the markup is not the source of truth anymore. The model is, and the record moves when the model moves.

An isometric 3D building model with an orange duct on the roof, linked by lines to three drawing sheets around it, showing the model as the single source of tru

An isometric building model with one wall shifted, linked by a direct line to a single issue record, while a faded second document is crossed out.
A quick note for anyone tempted to run this from a shared folder and a spreadsheet: those are fine for learning what a coordination log looks like, and most coordinators have tried a few. The reason firms move off them is not features. It is that a folder still leaves you maintaining two versions of the truth, and the three-inch move still slips through. If your real problem is design drift, a folder does not solve it. A live record does.

Start with the next design change that lands in your inbox. Before you forward it and wait, ask what it touches and who owns it. If you cannot answer that in a few minutes, you have found the actual problem. It is not the team. It is that the change was never attached to the model in the first place.

Related Lessons

Support

Responses