BIM Execution Plan: the 6 sections that actually get used

The 40-page document nobody reads

It is a Tuesday morning. The MEP coordinator has just flagged a Level 2 clash between a 600 mm duct and a 300 mm beam on gridline D-7. The structural lead is on another call. The information manager opens the project's BIM Execution Plan to check the coordination protocol — who owns the resolution, what the escalation path is, how the revised model gets reissued to the common data environment.

She scrolls past section 1: a four-paragraph preamble about the transformative potential of BIM on modern infrastructure delivery. She scrolls past section 2: a definitions glossary with thirty-one terms, beginning with "Asset Information Model" and ending with "Work In Progress." She scrolls past section 3: a two-page rehearsal of why the client chose BIM, lifted wholesale from the employer's information requirements they responded to eight months ago. She finds section 4.3.2, "Clash Detection and Coordination," which says — and this is verbatim from a real BEP seen in the field — "the project team will conduct regular coordination reviews in accordance with project requirements."

She closes the document. She sends a message to the BIM coordinator. The coordination process happens, correctly, based on institutional knowledge and a verbal agreement made in a kick-off meeting. The BEP is not consulted again for three weeks, when a junior architect needs to look up the file naming convention to submit a drawing set.

This scenario plays out on construction projects of every size, every procurement route, and every continent. The BIM Execution Plan is one of the most formally required documents in modern project delivery — mandated by ISO 19650-2, demanded by clients at tender stage, and inspected by auditors at project close-out — and it is also one of the most reliably useless documents produced during a project's lifecycle.

The reasons are structural, not personal. The people writing BEPs are experienced practitioners. The frameworks they are responding to are well-designed. The problem is that the document has accumulated decades of bureaucratic scar tissue: sections added to satisfy procurement checklists, preambles written to impress clients at tender, definitions copied from standards to demonstrate awareness of those standards. The result is a document optimized for compliance theatre rather than operational use.

This post makes a narrower, more actionable argument: within any BEP, regardless of its total length or the standard it responds to, there are six sections that drive actual day-to-day delivery decisions. When those six sections are written well — concretely, specifically, with real names and real dates and real format identifiers — teams use them. When they are written with the vague procedural language that dominates most BEPs in the field, they are ignored, and the project runs on institutional knowledge until something goes wrong.

We will look at what those six sections are, how to write each of them, what the common failure modes look like in practice, and how to structure the rest of the document so it supports rather than buries the content that matters. The argument is grounded in ISO 19650-2:2018, the UK BIM Framework guidance, the American Institute of Architects' E203 and G203 protocols, and the NBS BIM Toolkit — but the practitioner experience behind it comes from real projects where BEPs succeeded or failed in real time.

What a BEP actually has to do

The document's strange genealogy

The BIM Execution Plan did not arrive fully formed. It evolved through a succession of standards, national mandates, and practitioner frameworks, and understanding that genealogy explains why so many BEPs contain sections that serve no operational purpose.

The concept was formalized academically by the Computer Integrated Construction Research Program at Pennsylvania State University. The first version of the BIM Project Execution Planning Guide was published in 2009, with Version 2.0 following in 2010 and subsequent editions absorbed into the National BIM Standard — United States (NBIMS-US). The Penn State framework was deliberately broad: it catalogued twenty-four distinct BIM uses across design, construction, and operations phases, and provided a structured methodology for selecting which uses were relevant to a given project and planning their execution. It was a planning tool, not an operational manual, and it was designed to be populated collaboratively at the outset of a project.

In the United Kingdom, the Government Construction Strategy of May 2011 mandated "fully collaborative 3D BIM" for all centrally-procured public projects by 2016. This created institutional pressure to produce BEPs as compliance artefacts — documents submitted at tender to demonstrate BIM capability, reviewed by procurement panels with limited technical knowledge, and evaluated against checklist criteria. The effect was predictable: BEPs grew longer to satisfy more checklist items and became less useful as operational guides.

PAS 1192-2:2013, the British standard that preceded ISO 19650, introduced a more structured framework for the BEP, distinguishing between a pre-appointment BEP (submitted at tender, demonstrating capability and proposed approach) and a post-appointment BEP (confirmed after contract award, governing actual delivery). It also formalized the Master Information Delivery Plan and Task Information Delivery Plans as live schedules that sit within or alongside the BEP.

ISO 19650-2:2018 — the current international standard — superseded PAS 1192-2:2013 for UK projects and provided a more precisely structured framework for the BEP's mandatory contents. Annex A of the standard provides a table of required information for both the pre-appointment and confirmed BEP. The UK BIM Framework, administered by the former Centre for Digital Built Britain before its closure in 2022, produced guidance documentation that interprets and extends the ISO 19650 framework for practitioners.

The RIBA Plan of Work 2020 introduced the Digital Execution Plan as a conceptual evolution of the traditional BEP, reflecting the broader shift from model-centric BIM governance to whole-lifecycle digital data management.

This history matters because it explains the document's split personality. The BEP is simultaneously a procurement artefact (evaluated at tender, designed to demonstrate capability to a client) and an operational document (referenced daily by information managers, coordinators, and task team leads). These two purposes pull the document in opposite directions. Procurement artefacts grow toward comprehensiveness, reassurance, and length. Operational documents need to be concise, specific, and navigable. Most BEPs fail because they were written for the first purpose and never properly converted to the second.

What ISO 19650-2 actually requires

ISO 19650-2:2018 defines the BIM Execution Plan as "a plan that explains how the information management aspects of the appointment will be carried out by the delivery team." This definition is deceptively simple. The standard's Annex A provides a mandatory contents table that specifies what both iterations of the plan must include.

The pre-appointment BEP must contain: the proposed information delivery strategy; the proposed high-level responsibility matrix; the proposed technology and infrastructure; the proposed information standards; and a mobilization plan that covers team capability and capacity assessment.

The confirmed BEP — produced after contract award by the lead appointed party — must contain everything in the pre-appointment BEP, confirmed and expanded, plus: the information delivery strategy for the project (detailed, not proposed); the detailed responsibility matrix; the Task Information Delivery Plans from each task team; the Master Information Delivery Plan integrating all TIDPs; and the agreed methods and procedures for information production.

The UK BIM Framework Guidance Part 2 (third edition) expands this into practical operational guidance. It describes the BEP as the document through which the delivery team demonstrates that it has understood the Exchange Information Requirements — the client's specification of what information is needed, when, at what level of detail, and in what format — and can deliver against them. The BEP is the supplier's response to the EIR, in the same way that a commercial tender response responds to a specification.

This EIR-BEP relationship is the structural core of ISO 19650 information management. The EIR defines the "what, when, and why." The BEP defines the "how." When a BEP section does not correspond to something in the EIR, it is almost certainly filling space rather than serving a purpose.

What three audiences need from it

The BEP serves three distinct audiences with different information needs. Most BEPs are written for only one of them — the client — and fail the other two.

The client and appointing party need confidence that the delivery team has understood the information requirements, has the capability and infrastructure to meet them, and has a governance structure that will catch and correct failures. They read the BEP at tender, at contract award, and at project audits. What they need is clarity about roles and accountability, evidence of a realistic delivery schedule, and a legible description of how information will be produced and transferred. They do not need a glossary of BIM terminology, a history of the standard, or a statement about the benefits of digital construction.

The lead appointed party and information manager need an operational document they can use to manage the information workflow. They need to know: who is producing what, by when, in what format, through what process, with what quality checks, and how disputes are resolved. They also need to be able to update this document as the project evolves — as new subcontractors are appointed, as the scope changes, as the programme shifts. A BEP that cannot be updated without a full rewrite is a BEP that will not be updated.

Task team leads and model authors — the structural engineer, the mechanical engineer, the specialist subcontractor appointed at construction stage — need to find, quickly and without ambiguity, the specific requirements that govern their work: the file naming convention for the system they are on, the LOD level required at the next information exchange, the format in which they need to deliver their model, and the coordination meeting schedule. These people typically have no patience for a forty-page document and will locate their one or two relevant pages and ignore the rest. The BEP's job, for this audience, is to make those pages findable and unambiguous.

The drift between intent and use

Research and practitioner surveys consistently show a gap between what BEPs plan and what projects deliver. A 2018 study published in Advances in Civil Engineering examined BIM collaboration practices across multiple projects and found that roles defined in BIM execution plans were often not the same roles that actually made decisions in practice, with BIM managers and project managers creating competing sources of leadership that the BEP had not anticipated.

The Penn State CIC Research Program's validation of the BIM Project Execution Planning Procedure across seven project case studies found that while the guide improved communication and planning, practitioners regularly reported average gaps between planned and actual BIM processes — with benefits realized by less than half of users.

The problem is not a failure of intent. It is a structural failure of the document. When the six sections that drive delivery are buried in boilerplate, teams stop reading. When the RACI matrix is vague, responsibility defaults to whoever shouts loudest. When the file format specification says "IFC or as agreed," nobody agrees until there is a problem. When the coordination process section says "the team will hold regular meetings," nobody knows how regular, who chairs them, or what happens to unresolved clashes.

These are not edge cases. They are the normal operational experience of BIM on construction projects. The rest of this guide is about fixing them.

The six sections that drive delivery

A well-structured BEP has approximately eight to twelve sections of substance, plus appendices. Of those, six carry the operational weight. The other sections are either obligatory framing that the client needs for contractual purposes, or they are filler that should be removed.

The six sections are:

1. Project goals and information requirements — linked explicitly to the EIR
2. Deliverables and milestones — the MIDP and its relationship to the programme
3. Roles, responsibilities, and RACI — who makes decisions, not just who is on the team
4. Software, formats, and exchange protocols — the technical standards that govern interoperability
5. Coordination process — the actual workflow for clash detection, issue resolution, and model federation
6. Quality control and audit — how compliance is checked, by whom, and with what consequences

Each of these sections has a specific operational function. Each has common failure modes that are well-documented in practice. And each has a set of concrete requirements — names, dates, format identifiers, decision rules — that distinguish a usable section from a decorative one.

Section 1: Project goals and information requirements

This section answers the question: what are we trying to produce information for, and what does the client need that information to do?

It is not a list of BIM benefits. It is not a restatement of the standard. It is a project-specific description of the information outcomes required, cross-referenced to the EIR.

A well-written goals and information requirements section identifies the primary BIM uses for the project — typically drawn from the Penn State taxonomy or the UK BIM Framework's equivalent — and for each use, specifies: who needs the information, when they need it, what level of detail is required, and what decision the information will support. It then links each use to the relevant EIR clause so that the delivery team can audit compliance.

For example, on a healthcare project: the facilities management team requires COBie-compliant asset data for integration with their CAFM system by practical completion. The EIR specifies LOD 350 for all M&E equipment, COBie spreadsheet format, populated with manufacturer data including warranty periods. The BEP section on information requirements confirms how this will be delivered: which task teams are responsible for which asset categories, at which information exchange milestone the data will be submitted for validation, and what the validation protocol looks like.

This level of specificity — which most BEPs do not achieve — makes this section both a planning tool and an audit trail.

Section 2: Deliverables and milestones (MIDP)

This is the Master Information Delivery Plan: the consolidated schedule showing every information deliverable across all task teams, when it is due, who produces it, in what format, and against which milestone it is gated.

The MIDP is, in practice, the most frequently consulted part of the BEP. It is the document that information managers open on Monday morning to check what is due that week. It is the document that project managers refer to when expediting deliveries. It is the document that clients audit against at project reviews.

Most BEPs contain a MIDP that is either absent, incomplete, or structurally wrong. A common failure is a MIDP that lists document types — "Structural Model," "Architectural Model," "MEP Model" — but not individual deliverable containers, not the responsible task team, not the exchange format, and not the relationship to programme milestones. This is a list, not a plan.

A functional MIDP has rows for individual deliverable containers (the IFC export from the structural model at RIBA Stage 3, the COBie spreadsheet for HVAC equipment at practical completion) and columns for: task team, responsible individual, due date, exchange format, review period, approval authority, and dependency (what other deliverables this depends on or what this deliverable gates).

Section 3: Roles, responsibilities, and RACI

This section answers three questions: who are the people, what are their functions, and who makes which decisions?

ISO 19650-2 defines a hierarchy of roles: the appointing party (the client), the lead appointed party (typically the principal contractor or lead consultant), and appointed parties (task teams). Within this hierarchy, the standard requires that specific information management functions be assigned to named individuals or roles.

The UK BIM Framework Guidance Part A identifies these functions in detail. The key ones are: the information manager (or equivalent function, regardless of job title), who is responsible for the CDE and information governance; the BIM coordinator (or lead coordinator within a task team), who is responsible for model production and coordination within their discipline; and the BIM project manager function at the lead appointed party level, who integrates the TIDPs into the MIDP and manages the overall information workflow.

A RACI matrix in the BEP maps these roles against the key decision points in the information management process: who is Responsible for producing a deliverable, who is Accountable for approving it, who is Consulted during its production, and who is Informed when it is issued. Without this matrix, there is no mechanism for resolving the question "who decides this?" when a dispute arises — and on real projects, that question arises constantly.

Section 4: Software, formats, and exchange protocols

This section specifies, precisely, the technical standards that govern information production and exchange. It is the section that model authors and coordinators refer to when setting up their files.

It must cover: the CDE platform and access arrangements; the authoring software and version numbers for each discipline; the exchange file formats for each information exchange milestone (typically IFC 2x3 or IFC4 for geometric models, COBie for asset data, PDF for drawings, and native formats for internal working); the coordinate reference system and project base point; the file naming convention with the full syntax and worked examples; the layer and object naming convention; and the model breakdown strategy (how the building is divided into federated model files).

The ISO 19650-1 standard specifies a container naming convention that breaks file names into functional fields: project, originator, volume/system, level/location, document type, role, classification, number, and status code. The BEP section on software and formats should implement this convention for the specific project, with worked examples that any task team lead can follow without having to interpret the standard themselves.

Section 5: Coordination process

This is the section that should tell the MEP coordinator what to do with that Level 2 clash on gridline D-7. It almost never does.

A functional coordination process section specifies: the coordination meeting frequency and attendance; the clash detection schedule (how often, who runs it, which software, which disciplines, with what clash rules applied); the issue classification scheme (hard clash, soft clash, tolerance violation, metadata error — each with a defined response protocol); the escalation path when a clash cannot be resolved at coordinator level; the model freeze and release schedule relative to key programme milestones; and the CDE workflow states that govern how information moves from work-in-progress to shared to published.

It also specifies — and this is where most BEPs fail completely — the decision-making authority for design changes that result from clash resolution. When a duct needs to be rerouted to avoid a beam, who has the authority to approve the revised route? What is the RFI process? How long is the response window? What is the programme impact protocol?

Without answers to these questions, every significant coordination issue becomes a negotiation between disciplines with no clear resolution path, and the BEP's coordination section provides no guidance whatsoever.

Section 6: Quality control and audit

This section specifies how the project confirms that information is being produced to the required standard, not just that it has been produced.

It covers: the automated model checking protocol (the software tool — Solibri, Navisworks, or equivalent — the rule sets applied, the pass/fail criteria, and the minimum check frequency); the information review and approval workflow within the CDE; the internal audit schedule; the protocol for handling non-compliant deliverables; and the process for updating the BEP itself when project circumstances change.

Quality control in BIM is frequently left as a post-hoc activity — checking models at the end of each design stage against a long list of requirements that nobody had been managing continuously. The result is a wave of corrections at each stage gateway that delays the programme and erodes the trust of the client. A BEP that specifies continuous quality control — weekly model audits against the IDS (Information Delivery Specification), automated checking on every CDE submission, defined criteria for escalation — converts quality from a retrospective exercise into a live management function.

Writing each section

Section 1 in depth: Project goals and information requirements

The goals section is the BEP's strategic layer. It should be written last, once the MIDP and the RACI are in draft, because those documents reveal whether the stated goals are achievable with the team and timeline that have actually been assembled.

What it must contain:

A complete list of the BIM uses that apply to this project, drawn explicitly from the EIR. For each BIM use, a plain-language description of the information outcome, the party who will use it, and the decision it supports. The level of information need (formerly "Level of Detail" or LOD; in ISO 19650 terminology, the Level of Information Need or LOIN) for each major model element category at each project stage. Cross-references to the EIR clauses that each requirement responds to.

Template language:

"This project requires BIM to support the following primary uses: (1) Design coordination and clash detection throughout design and construction stages; (2) Quantity take-off and cost estimation at RIBA Stages 2, 3, and 4; (3) Facilities management handover in COBie format for integration with [Client FM System Name] at Practical Completion. These uses are defined in EIR Section 4.2 (Design Development Information Requirements) and EIR Section 6.1 (Operations Information Requirements). The Level of Information Need for each model element category is specified in the Information Delivery Specification attached as Appendix [X] to this Plan."

What to avoid:

Do not open this section with statements like "BIM is a collaborative process that enables project teams to generate and manage digital representations of physical and functional characteristics of places." This is true, appropriate for a training course, and entirely irrelevant to anyone who is managing information on a live project. The person reading this section needs to know what information is required on this project, not what BIM is.

Do not include a list of BIM benefits ("reduced clashes," "better cost certainty," "improved collaboration"). Benefits arguments belong in the client's business case for BIM, not in the delivery team's execution plan.

The LOIN (Level of Information Need) table:

The most operationally important sub-element of this section is the LOIN matrix — the table that specifies, for each major element category, what geometric detail and what non-geometric information is required at each project stage. This table is what model authors refer to when asking "how much detail do I need in this element right now?"

In ISO 19650 terminology, this breaks into: the geometric information need (the physical size, shape, location, and orientation of an element — formerly "Level of Detail") and the non-geometric information need (the attributes, data fields, and metadata associated with the element — formerly "Level of Information"). The NBS BIM Toolkit, before its retirement in July 2022, provided a structured database for defining these requirements that was linked directly to the Uniclass classification system. Its successor approaches — including commercial platforms like Plannerly and Autodesk Construction Cloud's information management tools — provide similar functionality.

The LOIN matrix should be maintained as a live document, updated when element categories are added, when stage requirements are revised, or when the EIR is updated through a variation. It should not be embedded as static text in a Word document.

Pitfalls:

The most common failure in this section is the disconnect between stated BIM uses and actual capability. A BEP that lists "4D construction simulation" as a primary BIM use when the project programme does not have a 4D BIM budget, the main contractor's team has no 4D modelling capacity, and the client has never specified a 4D deliverable in the EIR is not a plan — it is aspirational fiction. Listing a BIM use creates an obligation to deliver it. If the team cannot deliver it or the client has not required it, do not list it.

Section 2 in depth: Deliverables and milestones

The MIDP is the BEP's operational spine. Every other section — roles, formats, coordination, quality — feeds into and draws from the MIDP. A project with a weak MIDP has no reliable mechanism for tracking information production against programme, and no mechanism for identifying when a delay in one team's deliverables will cascade into other teams' work.

Structure of the MIDP:

The MIDP is a tabular schedule. Each row represents one information container — one deliverable at one milestone. The columns represent the attributes of that deliverable. The minimum column set is:

Container ID | Description | Discipline | Task Team | Responsible Author | 
Due Date | Exchange Format | Review Period | Approval Authority | 
Dependencies | Status | Notes

The container ID should follow the ISO 19650-1 naming convention, at least at the project-milestone level, so that the MIDP entry maps directly to the file name that will appear in the CDE.

TIDP to MIDP aggregation:

Under ISO 19650-2, each task team produces a Task Information Delivery Plan (TIDP) — their discipline-specific schedule of what they will produce and when. The lead appointed party's information manager aggregates these TIDPs into the Master Information Delivery Plan. This aggregation is where inter-team dependencies become visible: the structural engineer's Stage 3 model cannot be finalized until the architect's facade interface has been resolved; the MEP coordinator cannot complete the coordination model until the structural and architectural models are at the required LOIN.

These dependency relationships should be explicitly captured in the MIDP. Without them, the MIDP is a parallel list of schedules rather than an integrated delivery plan.

Sample MIDP structure (abbreviated):

## Information Delivery Plan — [Project Name]
### Version: 1.3 | Date: [Date] | Owner: [Information Manager Name]
 
| Container ID | Description | Disc. | Task Team | Author | Due | Format | Review (days) | Approver | Depends On |
|---|---|---|---|---|---|---|---|---|---|
| PRJ-ARC-ZZ-XX-M3-AR-0001 | Architectural Model Stage 3 | Architecture | [Firm A] | [Name] | 2026-09-15 | IFC 2x3 | 10 | Lead Designer | Structural Stage 3 (PRJ-STR-ZZ-XX-M3-ST-0001) |
| PRJ-STR-ZZ-XX-M3-ST-0001 | Structural Model Stage 3 | Structure | [Firm B] | [Name] | 2026-09-08 | IFC 2x3 | 10 | Lead Designer | — |
| PRJ-MEP-ZZ-XX-M3-ME-0001 | MEP Coordination Model Stage 3 | MEP | [Firm C] | [Name] | 2026-09-22 | IFC 2x3 | 10 | BIM Coordinator | ARC Stage 3, STR Stage 3 |
| PRJ-MEP-ZZ-XX-HC-ME-0050 | HVAC COBie Schedule PC | MEP | [Firm C] | [Name] | 2027-06-01 | COBie XLSX | 15 | IM / FM Team | Commissioning Records |

Milestone alignment:

The MIDP should be explicitly aligned to the project programme, not just to a separate internal BIM schedule. The information exchange milestones — the points at which a model is published to the CDE for client review or for use by downstream teams — should correspond to contractual stage gateways or decision milestones in the project programme. If the MIDP says that the Stage 3 architectural model is due on 15 September but the RIBA Stage 3 design freeze is on 1 September, there is a structural problem in the delivery timeline that needs to be resolved, not hidden.

Living document management:

The MIDP will change. Programme shifts, scope additions, subcontractor appointments, and scope creep all require MIDP updates. The BEP should specify the process for updating the MIDP: who can initiate a change request, who approves it, how version control is maintained, and how updated versions are distributed to task teams. A MIDP that is six months out of date is worse than no MIDP because it creates false confidence in a schedule that no longer exists.

Pitfalls:

The most common MIDP failure is granularity mismatch. A MIDP that lists "Structural Model" as a single row, due at "Stage 3," tells the information manager nothing useful. How many IFC files make up the structural model? Are they split by building level, by structural system, or by building volume? What level of detail is required for the Stage 3 submission vs. the Stage 4 submission? What is the review and approval timeline?

The opposite failure — a MIDP with two hundred rows for a twenty-unit residential scheme — creates an administrative burden that nobody maintains. The right level of granularity is one row per independently deliverable container per milestone. For most projects, this means somewhere between twenty and eighty MIDP rows across all disciplines and all stages.

Section 3 in depth: Roles, responsibilities, and RACI

The RACI matrix is the section that resolves the "who decides this?" question when it arises under time pressure. If it cannot be used as a quick reference during a coordination meeting, it is not working.

ISO 19650 role structure:

ISO 19650-2 defines roles at three levels. The appointing party (the client) is responsible for defining the EIR and the project's information management framework. The lead appointed party (typically the principal contractor or lead consultant) is responsible for appointing task teams, integrating their TIDPs into the MIDP, managing the CDE, and ensuring overall compliance with the EIR. Appointed parties (the task teams — individual consultants and subcontractors) are responsible for producing their assigned deliverables and for internal coordination within their discipline.

Within the lead appointed party, the UK BIM Framework Guidance Part A identifies the information manager function — the person (or role, on larger projects covered by a team) who manages the CDE, enforces naming conventions and status workflows, and acts as the primary point of contact between the delivery team and the client's information management function.

What the RACI matrix covers:

The RACI matrix should map roles against the key activities in the information management workflow, not against every task on the project. The activities to cover are:

• Model production and internal review
• CDE submission and status change (Work-in-Progress to Shared)
• Cross-discipline coordination review
• Clash detection and issue logging
• Issue resolution and model update
• CDE publication (Shared to Published)
• Client review and approval
• Stage gateway sign-off
• MIDP update and version control
• BEP amendment and reissue
• Audit and non-conformance response

For each of these activities, the RACI identifies: who is Responsible (does the work), Accountable (approves and is answerable for the outcome), Consulted (provides input), and Informed (notified of outcome). The matrix should use role names, not company names or personal names, so that it remains valid when individuals change.

Sample RACI (abbreviated CSV):

Activity,Information Manager,Lead BIM Coordinator,Discipline BIM Author,Project Manager,Client IM Function
Model production and internal review,I,C,R,I,I
CDE submission (WIP to Shared),I,A,R,I,I
Cross-discipline coordination review,C,A,R,I,I
Clash detection and issue logging,I,R,C,I,I
Issue resolution and model update,I,A,R,C,I
CDE publication (Shared to Published),A,C,R,I,I
Client review and approval,C,I,I,A,R
Stage gateway sign-off,C,I,I,A,R
MIDP update and version control,R,C,I,A,I
BEP amendment and reissue,A,C,I,R,C

Decision authority vs. input:

The RACI matrix is often written to be inclusive rather than precise — everyone is listed as "consulted" or "responsible" for most activities, producing a matrix that generates no clarity about decision authority. The discipline that matters is distinguishing Accountable from Responsible. On any given activity, there should be exactly one Accountable role. If there are two, there is ambiguity. If there are none, there is a governance gap.

For example: who is Accountable for a published model meeting the LOIN requirements specified in the BEP? This is usually left undefined in practice, with the result that LOIN compliance is everyone's responsibility and therefore nobody's. The BEP should make this explicit: the discipline BIM coordinator is Accountable for LOIN compliance within their model; the lead BIM coordinator is Accountable for coordination of the federated model; the information manager is Accountable for CDE governance and status workflow compliance.

Joint ventures and split accountability:

On joint venture projects, the RACI becomes structurally complex because both JV partners may have information management functions, and their relative authorities need to be resolved. The BEP should specify whether the JV has appointed a single lead information manager (preferred) or has split the function across the JV partners (acceptable but requiring explicit coordination protocols). The RACI should reflect whichever structure has been adopted, not gloss over the split.

Pitfalls:

The most common RACI failure is using company names instead of role names. "XYZ Architects is Responsible for model production" does not help when XYZ Architects has a team of fourteen people, three of whom are on this project, and the clash in question arrived on a Friday afternoon when the project BIM coordinator is on leave. The RACI should specify the role (Discipline BIM Author, Lead BIM Coordinator) and the RACI Appendix should map those roles to named individuals, with designated deputies.

Section 4 in depth: Software, formats, and exchange protocols

This section is the one that prevents the most common category of BIM project failure: interoperability breakdown. When two software tools cannot exchange information reliably, the information manager finds out too late, under programme pressure, when the consequence is a delay rather than a planning conversation.

Platform and software register:

The software register lists, for each discipline: the authoring software name, version number, and licence type; the exchange formats that software can produce natively vs. through export; and the CDE platform used for storage and workflow management.

This register should be populated before contracts are signed, not after. The pre-appointment BEP should include the proposed software environment; the confirmed BEP should reflect the actual confirmed tools. Discovering at mobilization that the structural engineer is on Tekla Structures 2023 while the architect is using Revit 2026 and the MEP team is on AutoCAD MEP is a coordination problem that should have been resolved in procurement, not discovered during the first coordination model federation.

Exchange format specification:

For each information exchange milestone in the MIDP, the BEP should specify the exchange format. The standard options in 2026 are:

• IFC (Industry Foundation Classes): The open standard for geometric model exchange, developed by buildingSMART International. IFC 2x3 is the most widely supported version; IFC4 offers improved data structure for infrastructure assets. The BEP should specify which version, and whether the export should be by building level, by discipline model, or as a single federated file.
• COBie (Construction Operations Building Information Exchange): The data standard for FM handover information, typically delivered as a structured spreadsheet. The BEP should specify which COBie schema version (UK 2012 vs. US NBIMS v2), the required data fields, and the validation protocol.
• IDS (Information Delivery Specification): The buildingSMART standard for machine-readable specification of information requirements. The BEP should reference the IDS file that defines the required properties for each model element, if the project has one.
• Native formats for internal working: The BEP should clarify that native Revit, Tekla, or Navisworks files are for internal working only and are not the contractual exchange format unless specifically agreed.

File naming convention:

The ISO 19650-1 container naming convention specifies a syntax with the following functional fields, separated by hyphens:

[Project] - [Originator] - [Volume/System] - [Level/Location] - [Type] - [Role] - [Classifier] - [Number] . [Status] . [Revision] . [Extension]

Example: PRJ-ARC-ZZ-L1-M3-A-201-0001.S3.P01.ifc

The BEP should define the project code and originator codes for all task teams, the volume/system breakdown for the project, the level codes, the type codes relevant to this project, and worked examples for at least three common container types (architectural model, structural model, MEP coordination model). Without worked examples, the naming convention will be applied inconsistently within the first month.

Coordinate reference system:

Every model on the project must use the same coordinate reference system: the same project base point, the same orientation, and the same units. The BEP should specify these precisely, with numeric coordinates for the project base point (ideally referenced to a national grid system), the agreed north direction, and the unit system. A survey model or reference model containing the agreed shared coordinates should be provided to all task teams at mobilization.

Coordinate misalignment is among the most common causes of model federation failure. It is entirely preventable through BEP specification and is entirely irrecoverable once models have been built in conflicting coordinate systems.

CDE workflow and status codes:

The CDE platform — whether that is Autodesk Construction Cloud, Aconex, Procore, BIM 360, or a bespoke solution — implements a status workflow for information containers. The standard ISO 19650 states use descriptive codes (Work-in-Progress, Shared, Published, Archived) but the BEP should specify any project-specific status sub-codes required by the client, the revision numbering protocol, and the access control policy (who can see what at each CDE status level).

Pitfalls:

The most damaging failure in this section is vagueness about exchange formats. "Models to be provided in IFC or native format as agreed" is not a specification. It is an invitation to a dispute six months into the project when the FM team discovers that the as-built IFC models do not contain the asset attribute data required for CAFM integration, because nobody specified which IFC properties needed to be populated.

The second common failure is a software register that is completed at contract award and never updated. Subcontractor appointments, software upgrades, and CDE platform migrations all change the software environment. The BEP's software register should be treated as a live document with version control.

Section 5 in depth: Coordination process

The coordination section is where most BEPs abandon specificity entirely. This is the section that must function as an operational manual for the information manager and BIM coordinator, and it is almost invariably the section written in the most vacuous procedural language.

The coordination workflow:

A functional coordination process section specifies the complete workflow from model production to clash resolution to model update. The workflow has discrete steps with defined responsibilities and defined timescales.

1. Model authoring: Each discipline BIM author produces their model in the authoring environment, meeting the LOIN requirements for the current stage as specified in Appendix A. Internal review and self-check against the project naming convention and coordinate system is completed before CDE submission.

2. CDE submission (WIP → Shared): The discipline BIM author submits the model to the CDE, changing status to Shared. The container is automatically available to the BIM coordinator and cross-discipline reviewers. Status change triggers a notification to the lead BIM coordinator and the information manager.

3. Automated model check: Within [X] working hours of Shared submission, the information manager runs an automated check against the project IDS using [specified tool]. Non-conformances are logged as issues in the CDE. Conformant models proceed to coordination; non-conformant models are returned to WIP status with a logged issue.

4. Model federation: The lead BIM coordinator federates the coordination model from all Shared discipline models on [day of week] each week. The federated model is available in the CDE for review by all task teams.

5. Clash detection: Clash detection is run using [specified tool and version] against the federated model. Clash rules are maintained in Appendix [X]. Detected clashes are classified as Hard (physical intersection, severity: Critical), Soft (clearance violation per specified clearance rules, severity: Major), or Tolerance (within modelling tolerance, severity: Minor — logged but not escalated).

6. Issue assignment: The lead BIM coordinator assigns each Critical and Major clash to the responsible discipline coordinator within [X] working hours of the coordination session. Assignments are made in the CDE issue tracker. Minor tolerance issues are batched and reviewed monthly.

7. Resolution and model update: The responsible discipline coordinator investigates the assigned clash, proposes a resolution, and updates the model. The resolution is proposed within [X] working days for Critical issues and [Y] working days for Major issues. If resolution requires a design change, the coordinator initiates an RFI against the relevant design authority.

8. Verification: The lead BIM coordinator verifies that the resolution has been correctly implemented in the updated model before the issue is closed. Closed issues are archived in the CDE with the resolution record.

9. Escalation: Unresolved Critical issues are escalated to the project manager and the relevant design authority lead within [X] working days. The project manager is responsible for establishing a resolution path with a programmed timeline.

Coordination meeting protocol:

The BEP should specify the coordination meeting schedule: frequency, attendees (by role), standing agenda structure, and the output documents required (clash report, issue log update, minutes). On most projects, a weekly coordination meeting for the principal disciplines (architecture, structure, MEP) and a monthly cross-discipline review with the client's technical adviser is a reasonable baseline. The exact frequency should be scaled to the programme velocity — during detailed design, weekly is appropriate; during scheme design, fortnightly may be sufficient.

Model freeze protocol:

Before major programme milestones — stage gateway reviews, planning submissions, contractor procurement packages — the BEP should specify a model freeze period: a period of [typically five to ten working days] before the milestone during which no new model updates are accepted in the CDE, allowing the coordination team to run a final clash detection pass and resolve outstanding issues. After the freeze, the models are published with a milestone status revision.

RFI and design change integration:

The coordination process section should reference the project's RFI process (typically defined in the contract, not the BEP) and specify how BIM-related design queries are formatted, who receives them, and what the response timeline is. The critical specification is that model updates arising from RFI responses must be made within a defined window (typically five working days of the RFI response) and that the updated container must be resubmitted to the CDE with the RFI reference number in the container metadata.

Pitfalls:

The most common failure in coordination process writing is using passive voice and vague temporal language. "Coordination meetings will be held regularly" tells nobody anything. "The lead BIM coordinator will chair a weekly coordination meeting on Thursdays at 10:00, attended by the discipline BIM coordinators for architecture, structure, and MEP, with a standing agenda item for outstanding Level 2 clashes" is a specification that team members can put in their diaries and follow.

The second common failure is specifying a coordination process that assumes tools or capabilities the team does not have. If the structural engineer is a small specialist firm with one licensed Navisworks seat shared between three project teams, a coordination process that requires daily Navisworks federation is not achievable. The process should be designed around the team's actual capacity, confirmed at mobilization.

Section 6 in depth: Quality control and audit

Quality control in BIM is frequently the afterthought section of the BEP — added last, written quickly, and consulted never. It should be the section that gives the information manager and the client confidence that information quality is being actively managed rather than discovered at stage gateway.

The three layers of BIM quality control:

Quality control in the BEP context operates at three levels, each requiring different tools and processes.

Level 1 — Geometric quality: Does the model represent the design intent correctly? Are elements at the right location, with the right dimensions, in the right relationships to adjacent elements? This is checked visually during coordination review and automatically by clash detection.

Level 2 — Data quality: Do model elements contain the required attribute data, classified correctly, with values in the specified format and within reasonable ranges? This is checked against the IDS using tools like Solibri Model Checker, IfcDoc, or BIMcollab Zoom. Data quality checking is the area most frequently neglected in practice — models can pass visual and clash checks while containing systematic data errors that will only emerge at COBie export for FM handover.

Level 3 — Process compliance: Are files named correctly? Are status codes applied consistently? Are required revision notes present? Is the CDE workflow being followed? This is checked through CDE auditing and can largely be automated through platform-level rule enforcement.

The audit schedule:

The BEP should specify a formal audit schedule with three components: automated checks (run on every CDE submission, flagging non-conformances in real time); periodic model audits (conducted by the information manager or a nominated auditor, reviewing a sample of containers against the full quality criteria, monthly during active design and weekly during construction stages); and stage gateway audits (a comprehensive review of all deliverables before each major milestone, conducted with client participation where required by the EIR).

Non-conformance protocol:

When a quality check identifies a non-conformance — a model element missing required data, a container with incorrect naming, a level of detail below the BEP requirement for the current stage — the BEP should specify: how the non-conformance is logged (in the CDE issue tracker, with the relevant BEP clause referenced); who is responsible for correction and within what timeframe; who verifies the correction; and what happens if correction is not made within the specified timeframe (escalation to the information manager, then to the project manager, with programme impact assessment if the non-conformance gates a downstream deliverable).

IDS and automated checking:

The Information Delivery Specification (IDS) is a buildingSMART standard published in its first stable version in 2023 that provides a machine-readable format for specifying property requirements. An IDS file defines, for each model element category, which properties are required, what their data types and value ranges must be, and which IFC entity they belong to. Automated checking tools can then validate any IFC file against the IDS in seconds, producing a detailed report of compliant and non-compliant elements.

Incorporating IDS-based automated checking into the BEP's quality control protocol converts a manual, time-consuming review process into a continuous automated function. The BEP should reference the project's IDS file (or the development process for one if it does not yet exist), the tool used for automated validation, and the minimum check frequency.

BEP self-update process:

The BEP is a living document. As the project evolves — new subcontractors are appointed, the programme changes, the scope is revised — the BEP must be updated to reflect current reality. The quality control section should specify the BEP update process: who can initiate an amendment, what the approval process is, how version control is maintained, how updated versions are communicated to task teams, and how the revision history is documented.

A BEP that is last updated at contract award and never touched again is a document that describes a project that no longer exists.

Pitfalls:

The most damaging quality control failure is deferring all checking to stage gateways. By the time the Stage 3 coordination model is being assembled for client review, systematic naming convention errors, missing COBie parameters, and incorrect coordinate references have been propagated through dozens of files across multiple disciplines. Fixing them under time pressure introduces new errors. Continuous automated checking prevents this accumulation.

The second common failure is treating quality control as a punitive exercise rather than a management function. The purpose of the audit schedule is to identify problems early enough that they can be fixed without programme impact, not to build a case for blame after delivery fails. The tone of the BEP's quality section should reflect this: quality is a management function, not an inspection function.

Anti-patterns

The definitions glossary

Most BEPs open with or include a multi-page glossary defining BIM terminology: "Asset Information Model," "Common Data Environment," "Exchange Information Requirements," "Level of Detail," "Information Manager," and so on. These glossaries are almost never read by anyone who does not already know the definitions. They are included because they appear in standard templates, because they signal awareness of the standard, and because they give the impression of thoroughness.

The actual cost of a definitions glossary is navigation overhead. Every time a practitioner opens the BEP looking for the file naming convention or the coordination meeting schedule, they scroll past the glossary. On a forty-page BEP, this is a minor irritation. On a living document that is opened dozens of times per week, it is a friction cost that compounds over the project lifecycle and contributes to the document being replaced by informal knowledge.

The fix: remove the standalone definitions section. Define terms inline, on first use, with a parenthetical or a footnote. If the client requires a glossary for contractual or procurement purposes, include it as an appendix that does not interrupt the main document flow.

The BIM benefits preamble

Related to the definitions problem is the BIM benefits preamble: a section — sometimes a full page — explaining why BIM is valuable, why the client chose to mandate it, and what outcomes it will deliver. This content was appropriate in 2013, when many clients were being introduced to BIM for the first time and needed a rationale for the mandate. In 2026, any client with an EIR has already made the case for BIM internally. Repeating that case in the BEP is not providing the client with useful information.

The benefits preamble also creates a subtle but significant problem: it sets expectations that the BEP then has to deliver against. If the preamble promises "enhanced collaboration, reduced rework, and improved project outcomes," and the coordination process section then specifies a clash detection process that any experienced practitioner can see is underpowered for the project's complexity, the gap is visible and uncomfortable.

The fix: remove the benefits preamble entirely. The first sentence of the BEP should state what it is ("This BIM Execution Plan sets out how [Project Name]'s delivery team will meet the information requirements defined in the Employer's Information Requirements version [X], dated [date]") and the second sentence should point to the structure of the document. Nothing else is needed in the opening section.

The philosophy section

A variant of the benefits preamble, the philosophy section articulates the team's approach to BIM: "Our team believes that information management is a collaborative discipline that requires open communication, mutual respect, and a commitment to shared goals." This language is appropriate in a company's marketing materials and in a kick-off presentation. It has no place in an operational document.

The philosophy section typically appears in BEPs produced by teams that are proud of their BIM culture and want the client to know about it. The client's information requirements, however, do not ask for a statement of values — they ask for a description of how information will be produced, managed, and delivered. The philosophy section answers a question nobody asked.

Unused sections

Standard BEP templates — from the Penn State guide, from CDBB, from commercial template providers — contain sections for every conceivable project type and procurement route. Applied without editing to a specific project, these templates produce sections that are not relevant, not achievable, or not required by the EIR.

Common examples include: a 4D simulation section on a project with no 4D BIM budget; a facilities management data handover section specifying integration with a FM platform that the client has not yet selected; a section on BIM for sustainability analysis specifying tools and processes that the team's sustainability consultant has never used; a section on virtual reality and immersive visualisation on a project where the design review process is a PDF review with a quantity surveyor.

Each irrelevant section has a cost: it increases document length, it creates audit exposure (if the section says the team will do X and the team does not do X, that is a non-conformance), and it signals to practitioners that the BEP was not written specifically for this project.

The fix: before finalising the BEP, review every section against the EIR and the confirmed project scope. If a section does not correspond to an EIR requirement or a confirmed project need, delete it. A twenty-page BEP that covers this project precisely is better than a forty-page BEP that covers every project in the abstract.

Copy from prior project without trim

The most pervasive anti-pattern in BEP production is copying the previous project's BEP and updating the project name on the cover page. This produces a document that may be structurally sound but is operationally wrong: the software register references tools the current team does not have, the MIDP dates are from the previous project's programme, the RACI names individuals who are not on this project, and the file naming convention uses volume codes from a building that has nothing to do with the current project.

This is not a hypothetical failure. Every experienced information manager has encountered a BEP where the project name has been updated but an internal reference to the previous project's name remains; where the MIDP submission dates are clearly from a different project's programme; where the RACI lists a BIM coordinator who left the firm two years ago.

The fix: establish an organisational BEP template that contains the structural skeleton (sections, column headings, process diagrams) but no project-specific content. Every BEP on a new project is built from the template, not from the previous project's completed document.

Case studies

Case Study 1: District energy scheme, 45,000 m², public sector (composite)

A district energy infrastructure project for a local authority, delivered under NEC4 ECC, with a principal contractor appointing six specialist subcontractors including the energy centre mechanical and electrical contractor, the civils contractor for the distribution network, and the controls and BEMS contractor.

The BEP challenge: Six task teams with different software environments (Revit for above-ground architecture, Bentley OpenBuildings for below-ground civils and utilities, ETAP for power systems, AutoCAD MEP for building services within the energy centre, and two specialist subcontractors with no BIM authoring capability at all). A client EIR specifying COBie handover for all assets above a specified replacement cost threshold, IFC 2x3 federation models at RIBA Stage 3 and Stage 4, and Bentley AssetWise integration at practical completion.

What the BEP got right: The software and formats section was written with unusual rigour. It acknowledged the heterogeneous software environment explicitly, specified the IFC export parameters for each discipline (including discipline-specific export configurations tested before contract award), specified that the two non-BIM subcontractors would provide asset data in COBie spreadsheet format populated from their O&M documentation, and specified the aggregation workflow for integrating their data into the federated COBie at practical completion.

The coordination process section adapted the standard clash detection workflow to accommodate the civils model, which was in a different coordinate reference system from the above-ground building models. It specified a transformation procedure and a coordination zone at the interface between the above-ground and below-ground scope, with a named individual responsible for managing that interface.

What the BEP got wrong: The MIDP was initially produced as a single table with one row per discipline and one column per RIBA stage. When the energy centre design scope was separated from the distribution network scope (different programme streams), the MIDP could not represent the split without a major restructure. The BEP required a formal revision at the end of Stage 2, and the MIDP was rebuilt with separate sections for the energy centre stream and the distribution network stream, with explicit cross-stream dependencies for the interface zone.

Lesson: A MIDP that does not reflect the actual programme structure of the project is not a MIDP. On multi-stream projects, the MIDP must be structured to reflect the parallel workstreams and the interface dependencies between them. This structure should be agreed at mobilisation, before the MIDP is populated with delivery dates.

Case Study 2: 120-unit residential scheme, private developer, design-build (composite)

A mixed-tenure residential scheme, private developer, design-build contract, with an architect novated to the main contractor at RIBA Stage 2+. The developer's EIR specified BIM Level 2 compliance, COBie handover for FF&E and M&E assets, and clash-free models at RIBA Stage 4.

The BEP challenge: The novation of the architect created a role transition problem. The pre-appointment BEP had been produced by the architect as lead designer. After novation, the main contractor became the lead appointed party, but the architect retained the BIM coordination function in practice. The BEP's RACI section had not been updated to reflect the post-novation role structure, creating an ambiguity about who was accountable for MIDP management and CDE governance.

What the BEP got right: The file naming convention section was exceptionally well-specified, with worked examples for every discipline and every document type in use on the project. The main contractor's information manager had invested time in producing a one-page reference card extracted from the BEP naming convention section, which was issued to every task team at their appointment and pinned on the wall of the site BIM office. Naming convention compliance was consistently above 95% throughout the project, which the information manager attributed directly to the reference card.

What the BEP got wrong: The RACI was never updated to reflect the post-novation structure. The accountability gap for MIDP management — formally the lead appointed party (now the contractor), functionally still the architect — produced a six-week period during Stage 4 detailed design where the MIDP was not being updated by either party. The information manager discovered the gap during a routine audit and escalated it to the project manager. The resolution required a formal BEP amendment specifying that the contractor's information manager held MIDP accountability, with the architect's BIM coordinator delegated operational management under a sub-arrangement.

Lesson: Any change in the project's contractual structure — novation, additional appointments, change of lead consultant — must trigger a BEP RACI review. The RACI is not a static document; it is an operational tool that must reflect the current project team structure at all times.

Case Study 3: Transport terminal refurbishment, operational constraint, multi-phased (composite)

A major refurbishment of an operational transport terminal, phased over four years to maintain operational continuity. The client's EIR specified clash-free models before each construction phase commencement, with BIM models used to plan temporary works and phasing sequences.

The BEP challenge: The operational constraint meant that the construction programme was divided into ten phases, with different scope and different subcontractor packages in each phase. The MIDP needed to be structured around the phased programme rather than the standard RIBA stage model, and the clash detection process needed to incorporate the interface between the permanent works model and the operational asset model (the existing terminal, maintained as a BIM model by the client's facilities management team).

What the BEP got right: The coordination process section was written as a phase-by-phase workflow, with a separate coordination period defined for each phase that reflected the construction window and the operational constraint. The interface between the delivery team's models and the client's existing asset model was managed through a defined model exchange protocol with the client's FM team: the client provided an updated IFC of the existing building at the start of each design period for that phase; the delivery team incorporated it as a reference model for coordination; changes to the existing building identified during the phase were communicated back to the client's FM team through a defined data exchange.

The quality control section included a phase gateway audit: before commencement of each construction phase, the information manager conducted a full clash detection pass between the construction package models and the existing building reference model, with a confirmed zero-critical-clash requirement before the phase could commence.

What the BEP got wrong: The initial BEP assumed a single information manager function for the full project duration. By Phase 3, the project team had changed significantly, the information manager had rotated, and the institutional knowledge of the coordination protocol with the client's FM team was not adequately documented. The handover between information managers was difficult, and the Phase 3 kick-off experienced a three-week delay while the incoming information manager reconstructed the FM data exchange protocol from emails and meeting notes.

Lesson: The coordination process section should document the interfaces with external parties — particularly the client's FM team, utility companies with as-built data obligations, and any third-party data sources — in sufficient detail that the process can be understood and executed by someone who was not present at its inception. Process documentation is not bureaucracy; it is institutional knowledge made portable.

Limits and caveats

Public sector vs. private

The ISO 19650-2 framework was developed with significant input from UK public sector procurement practice and reflects the contractual and governance structures of that context. Public sector BEPs are typically reviewed by a client information management team with BIM expertise, assessed against explicit checklist criteria derived from the EIR, and audited at defined project stage gateways.

Private sector projects often lack these structural controls. The EIR may be less prescriptive, the client's information management function may be limited or absent, and the BEP may be produced to satisfy a contractual obligation rather than a genuine information management need. In this context, the six sections identified in this post are even more important, because they provide the internal discipline that the external governance structure does not impose.

The AIA's E203–2013 Building Information Modeling and Digital Data Exhibit and its successor G203–2022 BIM Execution Plan document take a different contractual approach: they attach the BEP as an exhibit to the construction contract and create legally binding obligations for the information requirements specified within it. This contractual embedding of BIM governance is less common in the UK ISO 19650 framework, where the BEP is typically referenced in the contract but not embedded as a contract exhibit. The AIA approach creates stronger enforcement mechanisms but also greater legal risk if the BEP is poorly drafted.

Joint venture BEPs

Joint venture projects create a structural problem for BEP governance: there are two (or more) entities sharing the lead appointed party function, each with its own BIM capability, its own software environment, and its own information management culture. A JV BEP that does not explicitly resolve how the JV's internal information management function is organized — including which JV partner provides the CDE, who manages the information manager function, how version control is maintained between JV partners' internal working environments — is a document that will fail in practice regardless of how well its other sections are written.

The most reliable approach is to appoint a single information manager who is accountable to both JV partners, with a defined escalation path to the JV board for decisions that cannot be resolved at information management level. The RACI matrix should reflect this structure.

Mega-projects and programme-level BEPs

On megaprojects — major infrastructure programmes, large campus developments, city-scale public realm projects — the BEP operates at multiple levels simultaneously. A programme-level BEP sets the overarching information management framework; project-level BEPs adapt that framework for individual project packages; and contractor-level BEPs specify the task team implementation within each package.

This hierarchy requires careful governance: the programme-level BEP should specify which elements are mandatory and non-negotiable at project and contractor level (coordinate reference system, CDE platform, IFC version, COBie schema) and which elements can be adapted by project teams (authoring software, internal coordination meeting frequency, internal model checking tools).

Without this governance hierarchy, programme-level information management degrades into the same fragmentation problem that the BEP is supposed to prevent — but at scale, with potentially dozens of project teams using incompatible systems and producing information that cannot be aggregated at programme level.

The document is not the practice

This is perhaps the most important caveat of all. A well-written BEP does not guarantee well-managed information. It creates the conditions for well-managed information. The practice depends on people who understand the document, are committed to following it, have been trained on the tools it specifies, and have the authority to enforce compliance when it fails.

A BEP that is too complex for the team to follow is as useless as one that is too vague to guide them. The practical discipline of BEP writing is calibrating the specified processes to the team's actual capability and the project's actual complexity — not to what looks impressive in a tender submission, and not to what the most demanding possible client might conceivably want.

Sources and further reading

Primary standards and frameworks

ISO 19650-2:2018 — Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 2: Delivery phase of the assets. Geneva: ISO. The foundational standard for BEP requirements. Annex A provides the mandatory contents table for pre-appointment and confirmed BEPs. Available at iso.org.

UK BIM Framework Guidance Part 2 — Information management according to BS EN ISO 19650: Processes for Project Delivery (Third Edition). Centre for Digital Built Britain / UK BIM Alliance. Practical interpretation of ISO 19650-2 for UK projects, with worked examples of BEP structure and MIDP format. Available at ukbimframework.org.

UK BIM Framework Guidance Part A — The information management function and resources (Edition 2). UK BIM Alliance. Defines the information manager function, capability requirements, and accountability structure. Available at ukbimframework.org.

AIA E203–2013 — Building Information Modeling and Digital Data Exhibit. American Institute of Architects. The contractual framework for BIM governance on US projects, requiring parties to develop BIM protocols through G201 and G202 forms. Available at aiacontracts.com.

AIA G203–2022 — BIM Execution Plan. American Institute of Architects. The 2022 successor document providing a standardized format for BIM Execution Plans in US contractual practice. Available at aiacontracts.com.

Practitioner frameworks

Penn State BIM Project Execution Planning Guide, Version 2.2 — Computer Integrated Construction Research Program, Pennsylvania State University. The foundational practitioner guide for BEP development, introducing the BIM Uses taxonomy and structured process mapping approach. The methodology was incorporated into NBIMS-US Version 2. Available at psu.pb.unizin.org.

NBS BIM Toolkit — NBS (National Building Specification). Provided digital plan-of-work templates linked to the Uniclass classification system for defining LOD/LOI requirements. Retired in July 2022; successor approaches include commercial BIM management platforms. Historical documentation at thenbs.com.

Revizto — Understanding TIDP and MIDP: Key BIM Documents for ISO 19650 Projects. A practical guide to TIDP and MIDP structure, field definitions, and integration with the BEP. Available at revizto.com.

Academic references

Developing Standard BIM Execution Plans for Complex Construction Projects — Applied Sciences 14(15), 2024. Examines the gap between planned and actual BIM processes in practice and proposes a framework for improving BEP standardisation at organisational level.

Development of BIM Execution Plan for BIM Model Management during the Pre-Operation Phase: A Case Study — Buildings 6(1), 2016. A case study of BEP implementation in a Taiwan building project, documenting the gap between BEP specification and practice.

BIM Collaboration Practices: An Exploratory Case Study — Advances in Civil Engineering, 2018, doi:10.1155/2018/7259659. Examines how BIM manager and project manager roles interact in practice, and the leadership ambiguity that BEPs frequently fail to resolve.

-->