This time I want to tell you a true story. More or less.
I stitched together a few real scenes, added a little glitter, adjusted the lighting, and turned them into one story. So if any of my fellow “checkers” recognise themselves between the lines, every resemblance to actual events is — as they say in the movies — almost accidental.
Off camera: we are involved, fortunately only at the edges, in a large construction site that has been slowed down by BIM.
Or, more precisely, by a certain way of doing BIM.
The recipe is remarkably reliable.
First ingredient: information processes that live on a different timeline from construction. Model deliveries and revisions follow the Information Delivery Plan, while the site follows its own programme. The two calendars meet occasionally, often by accident.
Second ingredient: people managing information without enough technical or construction knowledge. This can work only if the project can afford overlapping functions and if those functions communicate continuously.
Third ingredient: communication channels that do not actually intersect. BIM issues in one platform. Site instructions somewhere else. Client decisions in meetings. Supplier changes by email. Everyone is connected. Nobody is necessarily talking to the right person.
And then there is the parsley of every anti-BIM recipe: objectives that are not aligned vertically across the project.
Cut to a large, complex, crowded construction site moving at speed.
The electrical designer has issued 1:200 CAD drawings. As often happens, the devices are shown with approximate installation positions: “centre of column”, “height 2.70 m”, the kind of information an experienced installer can interpret together with technical specifications and real site conditions.
In the BIM model, however, everything is exact. Scale 1:1. Absolute coordinates. Every component aligned. Every object positioned exactly 2700 mm above finished floor level in the linked architectural model.
So far, so good.
Then coordination begins.
The client-side BIM Coordinator federates the models, runs clash detection and starts issuing tasks. A device overlaps another object by a few centimetres. An arrow appears. The message says: “move this.”
No construction priority. No quantified displacement. No explanation of whether moving a sign is equivalent to rerouting a cable, relocating a four-kilogram device or changing a service already installed.
Close-up.
Our BIM Coordinator asks: “Who decided this move?”
The BIM Specialist replies: “The issue arrived this morning. Didn’t you see the notification?”
And here the virtual installation begins.
The Specialist receives the issue, moves the object, updates the model, uploads the new version and closes the loop. Other specialists on other packages do the same thing at the same time, each interpreting their own instructions and deciding whether they need to ask a discipline expert, alert the site team or simply comply.
Now ask yourself a simple question: what are the chances that two different teams move two different objects too far, not far enough, or in the same direction — and create a new clash?
And what happens when those small digital displacements accumulate into a real technical problem?
Meanwhile, elsewhere in the project, the client decides to replace a 25 cm device with a 40 cm one. Or a pipe route changes. The decision travels through another meeting, another email chain, another communication route that the BIM team may not see because “it does not affect BIM.”
Except that BIM affects the project.
Every small change triggers another chain of adjustments. The loop feeds itself. The programme moves forward. Materials arrive. Subcontractors need answers. Models are being re-issued while the physical site is already building yesterday’s decision.
On site, the installer is still holding a 1:200 drawing. A three-centimetre adjustment may be completely invisible, especially when the device is represented by a symbol rather than by its true footprint and a dimensioned axis.
So we try to compensate. Revision clouds. Numbered notes. 3D screenshots. 1:20 sections. Key plans with dedicated codes.
Useful tools — but still only tools.
Without a BIM-management process that is aligned with construction, these additions become patches on a broken communication chain. Coordination meetings continue on a weekly cycle, often several days out of phase with the actual work. The installer ends up removing and reinstalling something that was already in the right place for yesterday’s version of the project.
And then the supposed efficiency of BIM becomes two costs instead of one: rework in the office and rework on site.
At Isegno we use a couple of deliberately simple rules alongside the usual information requirements.
Rule one: if it takes longer to model than to build, there is a good chance you are overmodelling. Not always, but often enough to stop and ask why.
Rule two: if the person installing the component understands that construction detail better than you do, do not replace their competence with false digital precision. Define the correct performance requirement, give typological information where appropriate, and develop the construction node properly instead of pretending that a coordinate is a design decision.
We are designers. Our job is not to colour models. It is to make construction possible.
This is where the paradox becomes uncomfortable.
If BIM exists to improve design and construction, why do some BIM processes make the site slower?
Because the model is not the project.
A model can be flawless and the decision behind it can still be wrong. A clash report can be accurate and the requested action can still be useless. A platform can distribute an issue instantly and the person who actually needs the information can still receive it too late.
The danger is not BIM itself. It is the seduction of control.
We begin to believe that if every object has coordinates, every issue has an owner and every revision has a timestamp, uncertainty has disappeared. It has not. Construction remains physical, sequential, contextual and full of human judgement.
The more complex the project becomes, the more this matters. On a small job, an awkward BIM workflow may be annoying but survivable. On a large one, multiplied across hundreds of people, models, packages and decisions, the same friction becomes expensive. Sometimes dangerously expensive.
The irony is that we built these systems to increase agility and coordination. Yet when every micro-decision is reflected through several layers of models, reviews, approvals and re-uploads, the project can become rigid. Information moves constantly while understanding stands still.
And the construction site becomes a battlefield between those who represent the project and those who have to build it.
There is another way.
BIM can still do what it promised: reduce waste, expose conflicts early, make information visible and help teams coordinate decisions before they become concrete, steel, cable trays and invoices.
But that requires a cultural change before a technical one.
Information deliveries have to respect construction timing. BIM teams need access to people with discipline and site experience. Site teams need enough BIM literacy to understand what the model can — and cannot — tell them. And issue management must support decisions rather than replacing them.
Most importantly, somebody has to own the question that no clash-detection engine can answer by itself:
Should this object actually move?
Building should be an act of collective intelligence, not an obstacle course between XYZ coordinates.
Design exists to be built.
And sometimes the most professional thing a BIM team can do is stop moving the virtual object for thirty seconds, call the person on site, and ask what is really happening.
