Methodology Synthesis 01

Information Governance for Collaborative Delivery

What ISO 19650 actually requires a project to decide before it starts exchanging information — and the control structures that turn those decisions into something enforceable rather than aspirational.

1. The failure this addresses

The economic case is not in dispute. The National Institute of Standards and Technology estimated the annual cost of inadequate interoperability in the U.S. capital facilities industry at approximately $15.8 billion, with roughly two-thirds of that burden falling on owners and operators during the operations and maintenance phase rather than during construction. The cost of information failure is paid mostly by whoever inherits the building.

What is less widely appreciated is that this failure persists on projects that did everything the technology literature recommends. Peer-reviewed research published in Automation in Construction documented a $113 million, 200,000-square-foot university research facility that had a formal BIM Execution Plan, applied COBie data formatting, and operated under an IPD collaboration philosophy — and whose automated data exchange into the computerized maintenance management system still failed at handover. The cause was not a missing standard or an unsuitable file format. It was the absence of dedicated information governance: no one held defined authority over what information had to exist, in what state, verified by whom, before it could be transferred.

That is the distinction this document is built on. A standard tells you what good information looks like. Governance determines whether anyone is obligated to produce it. Most projects have the first and not the second.

2. What ISO 19650 is actually asking for

ISO 19650 is frequently described as a BIM standard. It is more useful to read it as a procurement and accountability standard that happens to concern information. Its structure rests on a chain of requirements, each of which is a decision someone must make and own:

Two observations follow, and they are the ones most often missed in practice.

First, the chain runs backward from operations. Asset information requirements are derived from what the owner will need once the building is running, not from what the design team finds convenient to model. A project that begins by asking "what should we model?" has already inverted the sequence, and will discover at handover that it modelled the wrong things in the wrong depth.

Second, exchange information requirements belong in the appointment — the contract — not in a technical appendix circulated after award. An information requirement that is not contractually owed is a request. Requests are honored when schedule and budget permit, which at handover is precisely when they do not.

3. The decisions to make before any information moves

The following sequence consolidates what ISO 19650-1 and 19650-2, the AIA digital practice documents (E203, G201, G202, G203), and the BIMForum LOD Specification each require, expressed as decisions rather than as documents. Each has a named owner and a point in the project at which it becomes irreversible in practice.

Decision 8 deserves particular attention because it is the one most often treated as a storage question. It is a liability question. When a dispute arises over what information a party held at the moment it made a decision, the only admissible answer comes from a system that retained the superseded state rather than replacing it.

4. Three mechanisms that make governance enforceable

Decisions 4 through 8 above share a property: none of them survives contact with a live project on goodwill alone. Each requires a technical control that makes the intended behavior the only available behavior. In practice there are three, and they are worth naming separately because teams routinely implement the first and assume it covers the other two.

Role-based permission — who may act

Groups of users are granted defined capabilities against defined classes of information. This is the control most systems implement, and the one most teams stop at. On its own it is insufficient, because it governs the type of information a role may touch, not which instances.

Record-level visibility — which instances they may see

Rules restricting a role to the specific records it is entitled to, rather than to the whole class. On a multi-party project this is what allows genuinely shared infrastructure: a trade contractor operating inside the common data environment sees its own scope, not every party's commercial position. Without it, teams fall back on separate systems per party — which reintroduces exactly the fragmentation the common data environment was intended to eliminate.

Immutability of closed states — when information may change at all

Once a container is approved and issued, or a period is closed, it becomes fixed. Later corrections are made as new revisions, not as edits to the prior one. This is the least commonly implemented of the three and the one that determines whether the record is evidentially useful, because it is what makes "this is what we held on that date" a verifiable statement rather than an assertion.

5. A minimum viable governance regime

Full ISO 19650 conformance is out of reach for most small and mid-sized firms, and pursuing it as an all-or-nothing proposition is why many never begin. The following is a reduced set that captures most of the available benefit and can be written into an appointment without specialist support:

1. A single named individual accountable for information on the project, with the authority to refuse an issue that fails its check. Not a committee.
2. Exchange information requirements attached to the contract, listing deliverables, formats, timing, and the responsible party — one page is enough to start.
3. A defined set of container states, with a named authorizer for each transition.
4. Permissions configured to that state model, including record-level restriction where parties share the environment.
5. Superseded revisions retained, never overwritten.
6. A pre-issue check that is a specified list, performed by someone other than the author.
7. Asset information requirements drafted with whoever will operate the building, before design documentation begins.

Item 7 carries the highest return and is the most frequently skipped, because the operator is usually not yet under contract when the decision has to be made. That sequencing problem is procurement's to solve, not the design team's — and naming it as such is often the most useful contribution an information manager makes.

6. What this does not claim

Nothing here is an original technical contribution. Every underlying requirement exists in published standards, and this document's only work is consolidation and translation into decision form. Its intended reader is a firm that has been handed a digital delivery requirement it does not have the internal capacity to interpret, and needs to know which decisions actually matter and in what order.

Where a decision has legal consequence — allocation of liability, ownership of information, obligations surviving completion — it must be drafted by counsel licensed in the relevant jurisdiction. This document identifies the decisions. It does not draft the instruments.

References

• ISO 19650-1:2018 and ISO 19650-2:2018 — Organization and digitization of information about buildings and civil engineering works, including building information modelling: concepts and principles; delivery phase of the assets.
• ISO 31000:2018 — Risk management — Guidelines.
• National Institute of Standards and Technology, GCR 04-867, Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry (2004).
• Pishdad-Bozorgi, P., et al. — research on BIM-to-facility-management data exchange failure at handover, Automation in Construction (2018).
• American Institute of Architects — E203 Building Information Modeling and Digital Data Exhibit; G201 Project Digital Data Protocol Form; G202 Project Building Information Modeling Protocol Form; G203.
• American Institute of Architects — C191 Standard Form Multi-Party Agreement for Integrated Project Delivery; C195; C197.
• BIMForum — Level of Development (LOD) Specification.
• buildingSMART — COBie (Construction Operations Building Information Exchange); National BIM Standard–United States.
• Song, J., Esmeral Jaramillo, D., Lu, Y.-P., Eskew, D., Abandoh, C., Nguyen, T., Pishdad, P., & Zeng, Q. (2026). Schedule delay in construction delivery methods under extreme uncertainty. In Proceedings of IGLC 34 (pp. 655–667). DOI 10.24928/2026/0315.