When BIM runs across several companies and disciplines, “which software,” “which origin do we align to,” and “who delivers what, when” all drift apart fast. A BEP (BIM Execution Plan) is where a team agrees on all of that on paper before starting. It isn’t the model — it’s the rulebook for how the model gets built and handed over.
- A BEP is an agreement document stating who builds what BIM deliverables, when, and in which format.
- It's the delivery team's response to the client's information requirements (the EIR).
- Under ISO 19650 it's produced in two stages: pre-appointment (with the bid) and post-appointment (once confirmed).
- Its value is deciding the things that cause disputes later — coordinates, naming, classification, detail level, deadlines — up front.
Why a BEP matters
Most BIM failures come not from technology but from misaligned logistics.
- Architecture exports at a shared origin, structure at survey coordinates → the models don’t line up when overlaid
- One model is highly detailed, the other sparse → the detail levels (LOD) don’t match and coordination stalls
- File names and classification are inconsistent → schedules and search don’t hold
- “When and what to deliver” is vague → deliverables aren’t ready at the deadline
A BEP prevents this by agreeing and writing it down before work starts. It’s a little effort up front, but far cheaper than fixing a dispute after the fact.
How the EIR and BEP relate
A BEP doesn’t appear in isolation. First the client states “what we want” as the EIR (Exchange Information Requirements); the delivery team answers “here’s how we’ll deliver it” as the BEP. Think of them as a requirement (EIR) and response (BEP) pair.
EIR (requirements)
- "What, when, in which format we want"
- Sets purpose, uses, deliverables, standards
- Prepared by the client (or their advisor)
BEP (the plan)
- "How we'll build and deliver it"
- Team, software, procedures, schedule
- Prepared by the design / construction team
What a BEP should contain
Formats vary by client and template, but the substance is broadly the same.
🎯 Goals & BIM uses
What BIM is for (visualization, quantities, coordination, facility management). Narrowing the uses makes the detail level easier to set.
👥 Roles & responsibilities
Who owns which model, and who coordinates and approves. Name the BIM manager and each discipline lead.
📐 Level of information
How far to develop each stage — align geometry and property detail (LOD / level of information need).
🧭 Coordinates, naming, classification
Shared origin and north, file-naming rules, classification system. Lock the assumptions that let models overlay.
💻 Software & formats
Tools and exchange formats (IFC and so on). Default to tool-neutral openBIM exchange.
🗓️ Deliverables & deadlines
What's delivered when (MIDP / TIDP). List the outputs per milestone.
Pre- and post-appointment BEPs
ISO 19650 frames the BEP as two stages at different times.
Pre-appointment BEP (with the bid)
At tender stage, sets out how the team intends to meet the EIR and its approach. Not yet confirmed — a "here's how we'll tackle it" statement.
Post-appointment BEP (once confirmed)
After the appointment, the team, schedule and procedures are confirmed and detailed. This is the version actually operated, updated as the project runs.
So a BEP isn’t “write once and done” — it’s a living document: outline at bid → confirmed after appointment → updated as work progresses.
Making requirements machine-readable
BEPs and EIRs are usually written in prose, but if you also express the required properties and detail level in a form a machine can check, operating the project gets much easier. That’s IDS (Information Delivery Specification): it states requirements like “this element must carry this property” machine-readably, so model checking can verify them automatically. Decide the promises in the BEP, then auto-check they’re kept with IDS — that pairing is where openBIM is heading.
A lightweight way to start on small projects
A BEP isn’t only a thick formal document. Even a handful of people on a small job get real value from a lightweight version.
- One page is fine: agree the coordinate origin, naming rules, exchange format, and deliverables + deadlines up front — that alone prevents most accidents.
- Coordinates and naming first: this is where most disputes live. Fix the shared origin, north, and file-naming convention before anything else.
- Decide the CDE location: enforce “the latest exists only here” (see what is a CDE), and express version and status in the name.
Summary
- A BEP is an agreement document for who builds what BIM deliverables, when, and in which format.
- It’s the delivery team’s response to the client’s requirements (the EIR).
- It’s a living document: outline (pre-appointment) → confirmed (post-appointment) → updated as work runs.
- Its biggest value is agreeing coordinates, naming, classification, detail level and deadlines before starting — and even small jobs benefit from a lightweight version.
A BEP isn’t glamorous, but it’s the foundation that decides whether BIM actually pays off — through federation, coordination and checking, quantities, and into facility management. For the wider vocabulary see the BIM & IFC glossary, and for where information lives see what is a CDE.