Multi-consultant Indian projects rarely have every party on the same BIM software, which makes the openBIM-versus-closed-workflow decision considerably less theoretical than it might sound and more a direct, daily driver of how much project time gets spent on file exchange rather than actual coordination work.
| Workflow | How data moves between consultants | Typical interoperability cost |
|---|---|---|
| Closed BIM (all parties on the same software/vendor) | Native file exchange, no format conversion needed | Low - but requires every consultant to standardise on one vendor, which is rarely realistic on large multi-consultant projects |
| openBIM (IFC-based exchange) | Each discipline works in its preferred software, exchanges via IFC | Moderate - some data/geometry loss on IFC round-trips, requiring quality checks after each exchange |
Why openBIM Has Become the Practical Default Despite Its Own Cost
Mandating a single BIM vendor across every consultant on a project is rarely achievable in practice, since different disciplines have genuine, defensible reasons to prefer different tools - Tekla for structural steel detailing, Revit for architecture and MEP - reasons that don't disappear just because a project owner would prefer everyone on one platform for simplicity. IFC's data loss on round-trip exchange is real but manageable with disciplined quality checks after each import, treating IFC exchange as a step requiring active verification rather than an assumed-clean handoff, which is precisely the discipline that prevents most downstream problems this workflow could otherwise create.
A Scenario Showing Where openBIM Discipline Actually Gets Tested
Picture a project where the structural consultant works in Tekla, the architect and MEP consultant both work in Revit, and all three need to federate their models together for coordination. Every time the Tekla-authored structural model gets exported to IFC and imported into the shared coordination environment, there's a genuine risk that certain parameter data - connection details, material properties that aren't part of pure geometry - doesn't survive the round-trip cleanly. A disciplined team runs a specific verification check after each IFC import, comparing key parameters against what the source model actually contains, catching translation loss before it propagates into a coordination decision made on faulty information. A team that skips this verification step and simply trusts the IFC import as accurate is the one that eventually discovers, usually at an inconvenient moment, that a critical connection detail didn't actually survive the exchange.
Why ISO 19650 Has Pushed More Projects Toward This Model
ISO 19650, increasingly referenced on Indian institutional projects, is explicitly software-agnostic and assumes an openBIM-style exchange model as its baseline, which is pushing more multi-consultant Indian projects toward IFC-based workflows by default rather than by active choice - a project following ISO 19650 principles is, in effect, already committing to the openBIM approach as part of following that broader standard.