ISO 19650 for Architects: What Changes on a Real Project

ISO 19650 for architects means a real shift in how drawings and models move through a project, not just a new folder-naming convention layered on top of familiar habits. The standard replaces informal file-sharing with a defined, four-state information container workflow, where every drawing or model an architect issues has to pass through explicit approval gates before another discipline can rely on it. In my practice, the biggest adjustment has not been learning new software, it has been accepting that an unapproved model update genuinely cannot be shared for coordination, even informally, once a project has committed to working this way.

What ISO 19650 Actually Standardizes

ISO 19650 is an international standard for managing information across a built asset’s lifecycle using building information modelling, and it is explicitly a process standard, not a software mandate. Published in two core parts, ISO 19650-1 for concepts and principles and ISO 19650-2 for the delivery phase of assets, it grew out of the UK’s earlier PAS 1192 framework and has since been adopted with national annexes across Europe, the Middle East, and increasingly North America. For an architect, the practical effect is that information exchange stops being an informal email-and-attachment habit and becomes a defined sequence of roles, responsibilities, and approval points that every party on the project has agreed to in writing before design work even starts. That written agreement is what makes ISO 19650 different from most BIM guidance architects have encountered before: it is contractual, not aspirational, and the full scope of what it covers is laid out in the official standard text at https://www.iso.org/standard/68078.html.

The BIM Execution Plan Becomes a Real Deliverable

Under ISO 19650, the BIM execution plan stops being an optional appendix and becomes the document that defines exactly what an architect is contracted to produce, at what level of detail, and by when. It typically develops in two stages: a pre-appointment BEP submitted as part of a bid response, demonstrating the team’s proposed approach, followed by a post-appointment BEP that becomes the binding reference once the project is awarded. Architects should expect the BEP to specify information requirements down to individual model elements, assign a named information manager responsible for coordinating exchanges, and define the task information delivery plan that schedules exactly when each discipline issues information relative to project milestones. Treating the BEP as boilerplate rather than a document worth negotiating is a common early mistake, since its content directly determines what an architect can be held to later if a delivery is late or incomplete.

Understanding the Common Data Environment Workflow

The common data environment is the single managed environment where all project information lives, and ISO 19650 requires every information container within it to sit in exactly one of four states at a time: Work in Progress, Shared, Published, or Archived. Work in Progress is restricted to the authoring team and should never be used by another discipline for coordination, no matter how tempting an informal peek is when a deadline is tight. Moving a container to Shared requires an internal approval step, moving it to Published requires formal authorisation from the appointing party, and moving it to Archived requires verification, creating an audit trail of exactly who approved what and when. This gated structure is the part of ISO 19650 that most directly changes an architect’s daily workflow, because it removes the informal grey area where a nearly-final drawing used to circulate for early coordination before anyone had formally signed off on it.

• Work in Progress: authoring team only, not for cross-discipline coordination
• Shared: internally approved, available for comment and coordination
• Published: formally authorised, contractual information for construction
• Archived: verified record, forms the project’s audit trail

Information Management Roles an Architect Will Encounter

ISO 19650 introduces named roles that did not always exist formally on pre-standard projects, and architects need to know which one they are likely to hold or report to. The appointing party, usually the client, sets the overarching information requirements. The lead appointed party, often the architect on a design-led project or the main contractor on a construction-led one, coordinates the wider team’s information delivery. Each firm, including the architect’s own practice, typically designates a task team information manager responsible for internal quality checks before anything moves to Shared status. Information management in BIM under this structure is deliberately distributed rather than centralized in one BIM coordinator role, which means an architectural practice now needs internal process ownership for information management the same way it already has ownership for quality control on drawings, rather than assuming a contractor’s BIM manager will absorb that responsibility for everyone.

What Changes in Deliverables and Approvals

The most visible change on a real project is that deliverables are now defined against specific milestones in the task information delivery plan rather than a general design-stage description, and each deliverable has an assigned level of information need rather than a vague expectation of completeness. An architect issuing a design development set can no longer informally decide it is ready; the container has to be internally checked, approved for Shared status, and in many cases formally authorised for Published status before a client or contractor can rely on it contractually. This adds process overhead early on, but it also protects the architect: because every approval is logged, there is a clear record showing exactly what was issued, by whom, and when it was authorised, which becomes valuable if a dispute later arises over whether a specific piece of information was available to another discipline at a given point in the project.

Common Misconceptions That Cause Early Friction

The most persistent misconception is that ISO 19650 is a Building Information Modelling software requirement, when it is actually agnostic to whichever authoring tools a team uses; compliance is about process discipline, not a specific platform. A second common error is treating the common data environment as just a shared drive with new folder names, when the standard requires an actual state-based workflow with defined approval gates, something a plain file server cannot enforce on its own. Architects also frequently underestimate the naming convention requirements, which specify a structured file-naming schema covering project, originator, volume, level, type, and role codes; inconsistent naming breaks automated filtering and search across a CDE and creates exactly the kind of confusion the standard was meant to eliminate. Addressing these misconceptions in the BEP negotiation stage, before information starts flowing, avoids weeks of retroactive cleanup once a project is already underway.

Frequently Asked Questions

What does ISO 19650 for architects change compared to standard BIM practice?

It replaces informal file-sharing with a contractual, four-state approval workflow in a common data environment, so every drawing or model has to be internally approved before another discipline can rely on it. Architects also gain a named information management role and a BIM execution plan that functions as a binding deliverable schedule, not just a reference document.

Is a common data environment just cloud storage with a different name?

No, a common data environment requires a defined, gated workflow where every information container moves through Work in Progress, Shared, Published, and Archived states with specific approvals at each transition. Plain cloud storage without that gated logic does not meet ISO 19650 requirements, even if the files themselves are technically stored in one shared location.

Who is responsible for the BIM execution plan on an ISO 19650 project?

The lead appointed party, often the architect on design-led commissions, coordinates the BIM execution plan, though every discipline contributes information requirements specific to their scope. Getting this document reviewed properly before signing an appointment is worth discussing directly with an architect through a consultation at https://wa-associates.com/book-a-consultation/.

Does information management in BIM under ISO 19650 require a specific software to comply?

No, the standard is process-focused and software-agnostic, defining roles, approval workflows, and information states rather than mandating any particular authoring tool. Compliance depends on whether the team follows the defined common data environment workflow and naming conventions, not on which BIM software license each firm holds.

What happens if an architect shares Work in Progress information with a contractor?

It creates a genuine compliance and liability gap, since Work in Progress information has not been internally approved and should never be used for cross-discipline coordination under ISO 19650-2. If another party makes decisions based on unapproved information, responsibility for resulting errors can become difficult to assign cleanly in the project’s audit trail.

Conclusion

ISO 19650 for architects is less about learning new terminology and more about accepting a structural change in how information moves through a project: gated, logged, and contractually defined at every stage rather than shared informally when it feels ready. Practices that negotiate the BIM execution plan seriously and build internal ownership of the common data environment workflow early tend to find the standard protective rather than restrictive, since it creates a clear record of who approved what, and when, if questions arise later in the project.