Key Takeaways
- A BEP is not a template you fill in once and forget- it is a living document that must be updated at every major project milestone.
- ISO 19650-2 defines two distinct BEPs: the pre-appointment BEP (a capability proposal) and the post-appointment BEP (confirmed delivery commitments). Most teams only produce one, and that is where problems start.
- The BEP responds to the Exchange Information Requirements (EIR). Confusing the two is the most common mistake on ISO 19650-aligned projects.
- LOD requirements in a BEP must be defined per discipline and per project phase-not as a single project-wide number.
- Even small-scale projects benefit from a scaled BEP. The document does not need to be 40 pages to be effective.
- Without a BEP, clash detection findings, model handover obligations, and data responsibilities become matters of opinion rather than contract.
What a BIM Execution Plan Actually Contains
Ask ten BIM managers what goes in a BEP, and you will get ten slightly different answers. The confusion is understandable - there is no single mandated structure across all regions. But the core content is well-established, and projects that cut corners on any of it tend to pay for it during construction coordination.
A complete BEP covers the following:
Project Information and BIM Goals: The project name, scope, key dates, and a clear statement of what BIM is being used to achieve on this specific project. Not a generic paragraph about how BIM improves coordination. Specific targets: clash-free federated model by Stage 4, COBie data delivered at handover, 4D scheduling tied to the structural sequence.
Roles and Responsibilities: Who holds the BIM Manager role, who coordinates across disciplines, who runs clash detection, and who approves model submissions. This section must name individuals or firms, not just job titles. Ambiguity here is the single largest contributor to coordination disputes during construction.
BIM Uses: A confirmed list of what BIM will be used for on this project: design authoring, clash detection, 4D sequencing, quantity take-off, facilities management handover, or a combination. Every BIM use listed generates obligations. Do not list BIM uses the team has no capacity to deliver.
Modeling Standards and LOD Requirements: File naming conventions, coordinate systems, modeling granularity per discipline, and LOD requirements at each project phase. This section is covered in more detail below, because it is where most BEPs are weakest.
Software and Technology: Software versions in use across all disciplines, file format requirements for model exchanges, plugin dependencies, and interoperability protocols. A structural team running Tekla and an architectural team on Revit need to agree on IFC export settings before coordination begins, not after.
Common Data Environment (CDE) Strategy: The platform used to manage project information (Autodesk Construction Cloud, BIM 360, Aconex, Dalux, or similar), access permissions, model states, and the naming convention that governs every uploaded container. Without a documented CDE workflow, shared folders become a coordination graveyard.
Quality Control and Quality Assurance: The model audit schedule, clash detection cadence, and who signs off on model submissions before they enter the shared state. A BEP that says "clash detection will be performed regularly" is not a quality plan.
Information Delivery Schedule: Which models, data sets, and documents are due, at what stage, in what format. This maps directly to the Master Information Delivery Plan (MIDP) under ISO 19650.
Pre-Appointment BEP vs Post-Appointment BEP: A Distinction Most Articles Ignore
ISO 19650-2 is specific on this point, and it matters practically. There are two BEPs, not one.
The pre-appointment BEP is prepared by the prospective delivery team during the tender or bid phase. It demonstrates capability - here is how we intend to manage BIM, here are the software tools we use, here is how we understand your EIR. It is essentially a proposal. It makes commitments at a level of detail proportionate to what the team knows at tender stage.
The post-appointment BEP is prepared after the contract is awarded. Now the team has confirmed scope, confirmed deliverables, and access to the full EIR. The post-appointment BEP replaces the pre-appointment version and must be more specific- exact software versions, named individuals, confirmed LOD schedules, and an agreed CDE structure. This is the document the project runs on.
Most teams produce a single BEP and call it done. The practical consequence: the document is either too vague to be useful during delivery, or too detailed to have been realistic at tender. The ISO 19650 two-stage approach exists for good reason. Both documents are worth the effort.
The BEP Is Not the EIR: And Mixing Them Up Creates Real Problems
This distinction is foundational, and it is routinely blurred in practice.
The Exchange Information Requirements (EIR) is produced by the client or appointing party. It defines what information the delivery team must produce the data, models, and documentation the client needs, expressed in terms of the project's purpose. It comes first.
The BIM Execution Plan is the delivery team's response to that EIR. It confirms how the required information will be produced, managed, and delivered.
The EIR sets the standard. The BEP commits to meeting it.
When a contractor prepares a BEP without first receiving or reading a proper EIR, the resulting document is essentially a default workflow document with no connection to what the client actually needs from the model. That is a coordination risk that usually surfaces during handover, when the client discovers the COBie data is incomplete or the LOD delivered is not what was expected.
LOD Requirements in a BEP: Why a Single Project Number Is Never Enough
This is where the common advice in this space is wrong. Most articles and many BEPs assign a single LOD to the whole project at a given stage. "This project will be modelled to LOD 300." That sentence is almost meaningless without discipline and phase context.
The LOD 300 vs LOD 350 distinction is particularly important for MEP coordination. LOD 300 means the element is modelled with approximate size, shape, and location sufficient for design intent. LOD 350 means the element includes connections, supports, and interface geometry with other building systems. That additional specificity is what makes clash detection genuinely useful rather than decorative. A BEP that does not distinguish between 300 and 350 for MEP trades at coordination stage is setting up the team for rework.
Who Actually Prepares the BEP?
The lead appointed party - typically the main contractor or lead design consultant, depending on the procurement route - is responsible for producing the BEP and coordinating input from all task teams. In design-build contracts, this is usually the contractor. In traditional procurement, it is often the architect or BIM Manager acting on behalf of the design team.
The BIM Manager does not write the BEP in isolation. Every discipline must contribute its own software protocols, modeling standards, and LOD commitments. The BIM Manager assembles these into a coherent document, resolves conflicts, and circulates it for team sign-off.
What the BEP should not be is a document one person writes, sends once, and files. It requires cross-discipline input, review, and - critically - revision at key project milestones.
Does a Small Project Need a BEP?
The short answer: yes, but scaled appropriately. A residential extension modelled in Revit does not need a 35-page ISO 19650-aligned BEP. But it does need documented agreement on: what LOD will be delivered and at what stage, where models are stored and who has access, how clashes will be resolved, and what the handover deliverable looks like. That can be two pages. Call it a BEP, call it a BIM Protocol, call it a project agreement - the content matters more than the label.
The projects where "we don't need a formal BEP, we're a small team" consistently causes the most problems are fit-out and refurbishment jobs involving multiple subcontractors. When there is no agreed naming convention, no agreed CDE, and no agreed LOD, a project with four different trade contractors modelling the same ceiling space independently will hit coordination problems that a half-day of BEP drafting would have prevented.
How the BEP Evolves Through the Project Lifecycle
A BEP written at tender and never touched again is a compliance document, not a project management tool. It must be updated at each major delivery milestone.
- At pre-appointment: capability proposal level, outline workflows, indicative software list.
- At post-appointment / Stage 2–3 start: confirmed team structure, named individuals, agreed CDE platform, confirmed software versions, detailed LOD schedule.
- At Stage 3–4 transition: LOD requirements escalate for structural and MEP trades. The BEP must reflect updated clash detection cadence and any revised coordination milestones.
- At Stage 5 (construction): contractor-specific modeling requirements come in - temporary works, fabrication models, as-built recording obligations. If subcontractors are producing their own BIM models, their obligations must be appended or referenced in the BEP at this point.
- At handover: the BEP should confirm the final COBie/IFC deliverable requirements, the model freeze date, and any FM-specific data fields the client's asset management system requires.
The Most Common BIM Execution Plan Mistakes
- Writing it to satisfy a tender requirement rather than to guide the project: A BEP that is deliberately vague passes a pre-qualification checklist and becomes useless the moment work begins.
- Listing software without confirming interoperability: Teams that confirm Revit, Tekla, and Trimble on one project without testing IFC exchange workflows discover incompatibilities during the coordination phase.
- Skipping the CDE workflow section: "We will use BIM 360" is not a CDE strategy. Access permissions, folder structure, container states, and approval workflows must be documented.
- Never updating the document: The BEP written at pre-appointment is a proposal. It must be revisited and confirmed - or revised - after contract award, and again at each stage gate.
- Treating LOD as a project-wide single number: As noted above - this produces models that are simultaneously over-specified in some disciplines and under-specified in others.
How ISO 19650 Governs the BEP and What Is Changing in 2026
ISO 19650-2:2018 is the primary international standard governing BIM information management during the delivery phase, and the BEP is one of its central artefacts. The standard defines the pre-appointment BEP, the post-appointment BEP, and their relationship to the EIR, MIDP, and Task Information Delivery Plans (TIDPs).
It is worth noting that ISO 19650 Parts 1 and 2 are currently under proposed amendment. Draft Information Standards for both parts were due for publication in early 2026, with proposed amendments scheduled for public review. Organizations working on long-term projects particularly infrastructure and large commercial schemes should anticipate minor structural updates to BEP requirements under the revised standard. The UK BIM Framework provides the most current implementation guidance in the interim.