Every architect knows the sinking feeling of a beam appearing exactly where the design called for a clean ceiling, or a duct route that was never going to fit above the false ceiling once the structural depth was final, and almost every one of those moments traces back to the same root cause, which is that the MEP consultant, the structural engineer and your own drawings were never truly looking at the same version of the truth at the same time. This post is for the practice that wants to stop discovering clashes on site, where they cost ten times what they would have cost on paper, and to run consultant coordination as a calm, tracked process instead of a scramble of emailed PDFs. Let me walk through where coordination breaks, and how to hold it together.
Coordination fails at the version, not the drawing
Here is the honest diagnosis, and it is uncomfortable because it is so ordinary. Coordination rarely fails because a consultant is careless, it fails because the structural engineer marked up "Rev C", the MEP consultant was still working off "Rev B" that you emailed a fortnight ago, and your own team had already moved to "Rev D", so all three were competent and all three were wrong about the same wall. The clash was baked in the moment three versions of one drawing started living in three inboxes.
That is the whole game. When there is one shared, current set of drawings that every consultant marks against, clashes get caught in coordination, and when there are scattered PDF versions, clashes get caught on site. This is why I treat coordination as a version-control problem before it is a design problem, and it is the same principle that runs through the stages of an architecture project, because design development is precisely the stage where this either holds or falls apart.
A coordination matrix so nothing is nobody's job
The second failure mode is the gap where a clash is technically everyone's problem and therefore nobody's, so the practical fix is to make ownership explicit. A simple coordination matrix, agreed at the start, decides who owns what interface, and it removes an astonishing amount of finger-pointing later.
| Interface | Who leads | Who must sign off | Where it is resolved |
|---|---|---|---|
| Beam depths vs ceiling design | Structural | Architect | Shared drawing set |
| Duct routes vs structural zones | MEP | Structural | Coordination markup |
| Electrical points vs finishes | MEP | Architect | Room-by-room specs |
| Plumbing shafts vs layout | MEP | Architect and structural | Shared drawing set |
| Slab openings and cutouts | Structural | MEP and architect | Drawing with pinned notes |
Agreeing this matrix takes one meeting at the start of design development, and it saves a dozen arguments later, because when a clash appears everyone already knows whose desk it belongs on and who has to bless the fix.
Key takeaways
- Most clashes are version-control failures, not competence failures
- A coordination matrix agreed up front turns "everyone's problem" into a named owner's job
- Catching clashes in coordination instead of on site is the difference between a paper fix and a demolition
Run coordination against one live drawing set
The mechanism that actually prevents clashes is boring and powerful: every consultant works against the same current drawing set, and every query or clash is raised as a pinned markup on the specific detail rather than as a loose email. When the MEP consultant flags that a duct will not clear a beam, that note sits on the drawing at the exact location, the structural engineer sees it in context, and the architect signs off the resolution in the same place, so the answer and the drawing never drift apart. This is the same pinned-markup discipline that keeps site queries under control, because a request for information and a coordination clash are really the same animal wearing different hats.
That first bar dwarfs the rest, and it is entirely preventable, because it is not a technical problem at all, it is a document problem that a single shared workspace solves outright.
Coordination is a profitability issue, not just a technical one
Let me connect this to money, because it is easy to treat coordination as a purely technical concern and miss that it is one of the biggest levers on your margin. A clash caught on paper costs a revised detail and a short conversation, while the same clash caught after the slab is poured costs breaking, redoing, arguing about who pays, and a delay that pushes your fee release back. Across a year of projects, the practice that coordinates well simply keeps more of what it earns, which is exactly the point I develop in improving architecture studio profitability.
There is also a documentation benefit that pays off in disputes. When every coordination decision is recorded against the drawing with a date and an owner, and any resulting change is captured as a variation, you have a clean trail if a client or contractor later questions who approved what. Professional standards from the Council of Architecture are built around exactly this kind of accountable record, and running a full project with that trail intact is what separates a practice that gets paid on time from one that argues about it.
A consultant-coordination routine that holds up
- Agree a coordination matrix at the start of design development, with named owners
- Keep one current drawing set that every consultant marks against, never emailed versions
- Raise every clash as a pinned markup on the exact detail, not a loose email
- Have the interface owner and the sign-off owner both confirm each resolution
- Push every accepted change to all consultants the same day it is agreed
- Capture any scope change as a billable variation, tied to the project record
- Keep the whole coordination trail dated, so disputes reference a record
Stop the tool sprawl that causes the sprawl of versions
The reason versions multiply is that the drawings, the consultants and the coordination notes live in different tools, so keeping them in step depends on someone remembering to forward the latest file to everyone, and that someone is human and busy. The structural answer is to stop relying on memory and run coordination in one connected system rather than five disconnected tools, where the drawing, the pinned clashes, the consultant tasks and the resulting BOQ and billing changes all sit together.
That is how Designa handles it, construction drawings carry pinned comments so clashes are raised in context, consultants get the coordination items on their task lists, and when a resolution changes a quantity the room-by-room specs and BOQ update in the same workspace, with any scope change flowing into milestone billing. If you are weighing tools on this specific capability, my buyer's guide to choosing studio software in India gives you a way to score them, and the broader complete interior project checklist from start to finish shows how coordination fits the wider run of a project. For a dense market like Mumbai, where consultants juggle many projects at once, this consolidation is the thing that keeps your coordination from becoming their afterthought. Bodies like the Institute of Indian Interior Designers and the wider interior design and architecture community all frame this as good practice, and it genuinely is.
Coordination done well is quiet, and that quiet is the sign it is working, because the clashes that never reached site are the ones you never had to fight about. See pinned-drawing coordination working on a real project at demo.designa.work, and when it fits your practice, the founding offer with done-for-you onboarding and a 7-day money-back guarantee is at go.designa.work.
Frequently asked questions
Why do MEP and structural clashes happen so often?
Most clashes are version-control failures, where consultants work off different revisions of the same drawing, so the coordination breaks before anyone even considers the technical detail.
What is a coordination matrix?
A simple agreement made at the start of design development that names who owns each interface and who must sign off its resolution, so no clash is left as everyone's problem and therefore nobody's.
How does coordination affect profitability?
A clash caught on paper costs a revised detail, while the same clash caught on site costs demolition, rework, delay and disputes, so good coordination directly protects your margin.
How should coordination queries be recorded?
As pinned markups on the specific detail of a single shared drawing set, with a named owner and a date, so the query and its answer stay together and hold up if a dispute arises later.