There's a reflex in construction that goes something like this: rework happens, someone messed up on site, let's send a strongly worded email and move on. At Disperse, we tracked this pattern across the projects we monitored. A wall gets built in the wrong location. A pipe run has to be ripped out and rerouted. An entire section of ductwork gets fabricated to the wrong dimensions.
And every time, the first instinct is to blame the people who built it.
But here's the thing: about 70% of rework incidents trace back to design inconsistencies or information gaps. Not sloppy craftsmanship. Not a welder having a bad day. The model was wrong, or the drawing was outdated, or the change was made but nobody told the people who needed to know.
The field built exactly what they were given. They were just given the wrong thing.
How big is the problem, really?
Rework accounts for roughly 52% of total cost growth on construction projects. Let that number sit for a moment. More than half of the budget overrun on your project isn't scope creep, or material price increases, or unforeseen ground conditions. It's doing the same work twice because the information was wrong the first time.
Globally, McKinsey puts the cost of construction inefficiency at $1.6 trillion per year. Studies show that 85% of projects across 20 countries over a 70-year period experienced cost overruns, averaging 28%. Rework alone consumes 5–10% of total project costs as a baseline — and that's the acknowledged rework. The rework that gets quietly absorbed into the programme and written off as "site variations" is much harder to measure.
One research study found that 48% of rework is driven by poor collaboration, with 26% attributed directly to miscommunication. Not technical failure — communication failure.
The version gap
Here's the pattern that keeps coming up in conversations. An architect updates the model on Tuesday. The structural engineer is working from Monday's version. The MEP subcontractor is working from a model that was exported two weeks ago. The site team has a set of drawings that were issued for construction three weeks before that.
Everyone thinks they're working from the latest information. Nobody is.
This isn't negligence. It's the natural consequence of a workflow built on file-based exchange. You export a model. You email it or upload it to a CDE. Someone downloads it. By the time they open it, it's already behind. And there's no reliable way for them to know what changed between their version and the current one without manually comparing the two — which nobody has time to do.
So they build from what they have. And when what they have is wrong, they build it wrong.
The change order cascade
Here's where it gets expensive. A design change on its own might be trivial — move a column 300mm, adjust a beam depth, reroute a cable tray. The change itself takes minutes in the model. But the downstream impact of that change can take weeks to fully resolve.
Move that column, and suddenly the ductwork that was coordinated around its original position doesn't fit. The sprinkler heads need to shift. The ceiling grid has to be redrawn. The lighting layout changes. Each of those changes might trigger further knock-on effects in other disciplines.
On a project with traditional workflows, these cascading impacts are discovered one at a time, usually at the worst possible moment — when someone tries to install something and realises it conflicts with something else that changed three revisions ago.
The result: change orders. Delay claims. Acceleration costs. And somewhere in the background, a project manager trying to explain to the client why the budget just went up 8% because of a column that moved 300mm.
What "catching it early" actually requires
Everyone agrees that catching design conflicts early is better than catching them on site. That's the whole premise of BIM coordination. But "early" has a very specific meaning: it means before the affected trades have started work.
With weekly or biweekly model exchanges and monthly coordination meetings, "early" often means "two weeks after the change was made but before we pour concrete." That's not early. That's damage limitation.
Real early detection means knowing about a change the moment it happens. It means the structural engineer moves that column at 2pm on Tuesday, and by 2:01pm, the MEP coordinator gets an alert saying "Column C-7 on Level 3 moved 300mm south — this affects your ductwork run between grids C and D."
Not a 500-line clash report next Thursday. A specific, targeted, actionable notification right now.
Making the model the messenger
The technology to do this exists. It's not science fiction. What's been missing is a layer that sits across all the discipline models — architectural, structural, MEP, facade, whatever — and tracks changes in real time across all of them.
Not a periodic sync. Not a weekly export. A live, federated view where every change is logged, diffed, and propagated to the people who need to know about it.
When that layer exists, rework stops being inevitable. Not because people stop making design changes — they won't, and they shouldn't — but because every change becomes visible immediately to everyone it affects. The version gap closes. The information lag disappears. And the field stops building from yesterday's drawings.
Stop blaming the boots on the ground
The next time rework happens on your project, before you send that email, ask one question: did the people doing the work have the right information when they needed it?
If the answer is no — and 70% of the time, it will be — the problem isn't in the field. It's in the gap between the model and the people who depend on it.
Close that gap, and you don't just reduce rework. You give your team back the hours they currently spend fixing things that should never have been wrong in the first place.
Harsh Singh is the co-founder and CEO of Criad, an AI-powered BIM platform that federates construction models into a single live source of truth with real-time change tracking. If rework is eating your margins, book a call or join the waitlist.