Guide

The BIM Execution Plan,
explained.

What a BEP actually is, what goes in every section, and how it goes from a tender promise to the document that governs construction. Built around the template we use on live projects.

JES Delivery14 min readISO 19650-2 · Clause 5.4

What a BEP actually is

A BIM Execution Plan (BEP) is the document that sets out how a project will produce, manage and exchange its information under ISO 19650. It is the appointed party's answer to the client's Exchange Information Requirements: the EIR says what information the project needs; the BEP says exactly how the delivery team will produce it. Under ISO 19650-2, it is the governing document for every information-management activity on the project. Model production, coordination, the Common Data Environment, quality gates, and asset handover all run from it.

Put plainly, it is the operational contract between everyone who produces information on the project. It names who models what, to what level of detail, by when, into which folder, named in which way, and checked against which criteria. Once it is confirmed with the appointing party, it stops being a plan and becomes part of the contractual framework that binds every design team, subcontractor, and specialist supplier under the appointment.

Pre-appointment vs post-appointment

There are two BEPs, issued at two different moments, and they do two different jobs.

  • The pre-appointment BEP is submitted with the tender. It demonstrates capability (the team's methodology, resource plan, and technology stack) so the client can judge whether the bidder can actually deliver. It is a sales document with teeth.
  • The post-appointment BEP is issued within an agreed window after award (typically 15 to 20 working days), confirmed with all task teams and agreed with the appointing party. It supersedes the pre-appointment version. Every named individual, platform, and protocol in it has been confirmed. It is no longer a proposal, it is the rulebook.

One detail that matters: in the confirmed BEP, named individuals cannot be swapped out without notifying the appointing party and getting the Information Manager's acceptance. The people are part of the commitment, not a detail to fill in later.

Contractor BEP vs consultant BEP

The structure is shared, but the focus is not. A consultant's BEP is built around design production. A contractor's BEP (the one this guide is built around) is built around the construction phase: fabrication-ready models, shop drawings, site and trade coordination, 4D sequencing, as-built verification, and asset information handover. If you are the contractor acting as Lead Appointed Party, your BEP also has to govern every subcontractor's BIM work, which is why it carries a layer the consultant version doesn't: Task Team BEPs and TIDPs.

What's inside a BEP

A complete contractor BEP runs to thirteen sections plus a set of appendices that hold the live registers. Here is what each section is doing, and why it's there.

01

Project information & scope

Project details, the project parties, reference documents (the EIR it answers, the contract, the programme), and the confirmed scope of BIM uses: construction modelling, shop drawings, 3D coordination, 4D/5D, fabrication, as-built, asset delivery.

02

Roles & responsibilities

The delivery team across three tiers: BIM Director (strategic), BIM Manager (operational, the single point of contact), and Coordinators (production). Plus the subcontractor Task Teams, their obligations, and a full RACI matrix for every information activity.

03

Information standards

The standards the project conforms to (ISO 19650, Uniclass 2015, RIBA Plan of Work), the confirmed technical parameters (coordinate system, units, software versions, IFC schema), and the naming convention every container must follow.

04

Common Data Environment workflow

The platform, the four information states (WIP, Shared, Published, Archive), the rules and authoriser for every state transition, the folder structure, and the modules in use. This is the spine of day-to-day delivery.

05

Model federation & coordination

Who owns the federated model, how often it's assembled, the confirmed model breakdown by discipline, and the construction-specific coordination: 4D integration, site logistics, installation sequencing, prefabrication checks.

06

MIDP & information exchange schedule

The Master Information Delivery Plan (every container, owner, LOD/LOI, and due date) and the exchange milestones it feeds. Below it, the Task Information Delivery Plans, one per task team, confirmed before any production starts.

07

LOD / LOI strategy

The Level of Information Need across construction stages (LOD 300 to 500): how much geometry and how much data each element carries at each stage. No trade package model is shop-drawing-ready until it reaches LOD 400.

08

Quality assurance

A three-tier framework (self-check, peer review, and formal audit) with the audit categories and pass thresholds defined up front, so "good" is a number a reviewer can check, not an opinion.

09

Clash detection & coordination

The clash tolerances (hard 0mm, soft 25mm, clearance 50mm), the run cadence, and the resolution SLAs by priority. No clash closes on a verbal "looks fine". Resolution is verified in the model.

10

Information security

The project's security classification under ISO 19650-5, the CDE controls (role-based access, MFA, encryption, audit logging, data residency), and the breach-notification timeline.

11

Risk register

The named information-delivery risks (EIR change, subcontractor competence, unresolved clashes, version drift, incomplete handover data), each with likelihood, impact, a mitigation, and an owner.

12

Training & competence

The BIM induction every team member completes before touching the CDE, and the ongoing competence requirements for management staff and subcontractor coordinators.

13

Technology stack

The confirmed software schedule (authoring, fabrication, coordination, 4D/5D, CDE, site management) with versions locked. No new tools or mid-project upgrades without approval.

The part everything runs through: the CDE

If one section earns its place above all others, it's the Common Data Environment workflow. Every information container moves through four states, and none of them advances without passing a gate and getting an authorised sign-off.

StateCodeWhat it meansWho authorises the move
Work in ProgressS0Under active development. Not for anyone else to rely on.Task Team Lead
SharedS1 / S2Internally checked, available for coordination.Lead to share; BIM Manager to accept
PublishedA / BVerified against EIR/BEP, formally approved for use.BIM Manager / Information Manager
Archiven/aSuperseded, retained for audit and as-built record.CDE Administrator

The discipline lives in the transitions, not the labels. A model can't go from WIP to Shared until it passes the Tier 1 self-check; it can't go from Shared to Published until coordination is complete and clashes are resolved. The states are how the BEP turns "we'll be careful" into a process.

A BEP works when a coordinator can use it to decide whether what they just received is acceptable, and act on the answer.

From the JES delivery floor

How "good" gets defined

The quality framework is what stops the BEP being wallpaper. Three tiers, each with a clear trigger:

  • Tier 1: Self-check, before a container moves to Shared. The modeller checks naming, classification, LOD for the stage, model health, and an internal clash check. Uploading a non-compliant file is a breach, not a slip.
  • Tier 2: Peer review, before Shared moves to Published. A coordinator checks federation, inter-discipline clashes, data completeness, and standards compliance.
  • Tier 3: Formal audit, before an information exchange. Every audit category is scored against a threshold and a report is filed.

And the thresholds are explicit: file and naming compliance at 100% (zero tolerance), model health at least 85%, LOD/LOI at least 90%, classification at least 95%, and zero critical clashes. A submission either clears the bar or it goes back to WIP with specific remediation instructions, and the exchange milestone holds until it passes.

What makes it real

The difference between a BEP that governs a project and one that sits in a folder isn't the document, it's three habits the document encodes. It names people, not roles. It makes the QA gates non-negotiable hold points in the programme, not steps to skip when the schedule is tight. And it gives every clause teeth: non-compliant files rejected at the CDE, missed milestones escalated, unresolved critical clashes pushed to director level within 48 hours of the SLA expiring.

Write it that way and the BEP becomes the document the team reaches for when they need to know what to do next, which is the only test that matters.

Want the template behind this guide?

The full contractor BEP: 13 sections, RACI matrix, CDE workflow, LOD/LOI schedule and audit checklists. Pre- and post-appointment. Free.

Get the BEP template