The most profitable moment of a project occurs months before the first mixer arrives. It happens in a room, with the structural, electromechanical, and architectural models superimposed on a screen, deliberately searching for all the places where the project contradicts itself.
It's called interference coordination, and that's exactly what it is: finding the point where a sanitary pipe crosses a beam, where an air conditioning duct won't fit under the slab with the planned ceiling, where an electrical tray and a fire suppression pipe occupy the same space. All these conflicts exist in any project. The only variable is who discovers them and when.
The math is brutal. Resolving a clash in the model takes a few hours from a skilled coordinator. Resolving that same clash on-site costs demolition, lost materials, labor, a change order, and days on the critical path that are paid for in financing interest. There's a difference of two or three orders of magnitude between the two, and it's always the same clash.
A medium-sized residential tower can accumulate several hundred interdisciplinary conflicts before it's even coordinated. Each of these conflicts represents a decision someone will have to make. The question is whether that decision is made by a coordinator with the three models in front of them and the structural design available for consultation, or by the foreman at three in the afternoon with a jackhammer and the concrete pour scheduled for tomorrow.
The most expensive case involves pipe penetrations through beams. When a pipe needs to pass through a structural element, that perforation must be planned, located, and calculated by the structural engineer, along with the necessary reinforcement. If it's done afterward, without calculations, in the wrong area of the beam, it ceases to be a plumbing issue and becomes a structural one. And structural problems that are addressed belatedly are the only ones that can't be hidden behind a ceiling.
That's why in the projects we manage, the rule is simple: a federated model with all disciplines, weekly coordination meetings with minutes and assigned responsibilities, and no element is left out without the approval of all three disciplines. It sounds rigid, and that's precisely the difference between a schedule that is met and one that is explained.
It's important to clarify that the tool itself doesn't coordinate anything. I've seen projects with flawless models and construction sites riddled with conflicts because the model was created for presentation, not for actual work. Coordination only works when there's a responsible party with the authority to make decisions, a schedule that ensures all disciplines deliver simultaneously, and a clear rule that anything not coordinated simply won't be built. It's a matter of process and management discipline, and only then of software.
There is an additional benefit that quickly became relevant in Latin America. Development banks and funds that finance real estate projects in the region are increasingly demanding more evidence of coordination before disbursing funds. A project that submits a coordinated model and a record of resolved conflicts demonstrates that it knows where its budget will be in eighteen months.
Every building is constructed twice: first in the model and then on the ground. The more problems there are the first time, the fewer surprises there will be the second.
Recommended readings:
