Understanding what a BIM Execution Plan is and possessing the competence to draft one for a live project are distinct skills, and practitioners are frequently assigned the latter having been trained only in the former. Our "What Is BIM?" guide introduces the BEP as the rulebook a Common Data Environment enforces - this guide addresses the practical discipline of actually producing that rulebook.

What a BEP Is For, Concretely

A BIM Execution Plan (BEP), occasionally denoted BxP, is the governing document that specifies how a project team will produce, manage, and exchange information throughout the course of a project. It is not a generic statement of BIM policy; rather, it constitutes the delivery team's specific, project-level response to the client's information requirements (designated under ISO 19650 as the Exchange Information Requirements, or EIR): what is to be modeled, by whom, to what level of detail, exchanged through which process, and verified against which standard.

In the absence of a BEP, the phrase "BIM on this project" tends to carry a slightly different meaning for each party involved, and these minor discrepancies - divergent LOD assumptions, inconsistent file-naming conventions, differing assumptions about who owns clash resolution - are precisely what materialize as costly rework once the team begins working from a single coordinated model.

Two Versions of the Same Document

Under ISO 19650, the BEP is not a single document but exists across two distinct stages:

The pre-appointment BEP (also termed the pre-contract BEP) is submitted by a prospective delivery team as part of a tender response, prior to contract execution. Its function is to demonstrate the team's proposed methodology and capability, that is, how it intends to satisfy the client's information requirements, rather than to fix every operational detail, since the team's composition and resourcing have not yet been finalized.

The post-appointment BEP (the detailed, delivery-team BEP) is produced following contract award by the now-confirmed delivery team, and is considerably more specific: it commits to named roles, an actual information delivery schedule, and the concrete standards and procedures the team will follow for the remainder of the project. This is the version consulted in daily practice.

Conflating the two documents, or treating the pre-appointment BEP as a sufficient final deliverable, remains one of the most common procedural errors at a project's first BIM-related milestone.

What Goes Into a BEP

Templates vary between organizations, but a genuinely useful BEP, as distinct from a document produced merely to satisfy a checklist, tends to address the same core elements:

  1. Project details and scope. The project itself, the parties involved, the reference documents to which this BEP responds (the client's EIR, the contract), and the confirmed BIM uses specific to this project: design coordination, 4D scheduling, 5D cost, fabrication, as-built delivery, facility management handover. Not every project requires every use, and enumerating only those genuinely applicable preserves the plan's integrity.
  2. Roles and responsibilities. The individual responsible for each information-management function, typically structured across tiers (a strategic BIM lead, an operational BIM manager serving as the single point of contact, and production-level coordinators), specified by named individual where possible rather than by job title alone.
  3. The LOD/LOI matrix. The level of geometric and informational detail expected of each model element at each project stage. This is where the abstract LOD scale introduced in our BIM overview becomes a concrete, verifiable table specific to this project.
  4. CDE workflow and folder structure. The organization of the Common Data Environment: its state workflow (Work in Progress, Shared, Published, Archive), the access permissions governing each state, and the file and folder naming convention to which the whole team commits.
  5. Naming conventions. File names, model names, sheet numbers, agreed once and recorded in writing, so that no party is left to guess or improvise a scheme several weeks into the project.
  6. Software and file formats. The authoring tools each party will employ, the version in use, and the interoperability format, typically IFC, used for exchange between them. This is where openBIM commitments become operationally concrete.
  7. The coordination and clash-detection process. The frequency at which federated models are reviewed, the software used, the party responsible for resolving each category of clash, and the criteria that must be satisfied before a clash may be closed.
  8. The delivery schedule: TIDPs feeding a MIDP. Each task team produces its own Task Information Delivery Plan (TIDP), specifying what it will deliver and when; these aggregate into a single Master Information Delivery Plan (MIDP) that tracks every deliverable across the project as a whole, and which is revised as the project progresses rather than fixed at kickoff.
  9. Quality assurance. The process by which model quality is verified prior to information being shared or published, whether through automated checks, manual review, or a combination of both, and the party responsible for sign-off.

Writing One Without Overbuilding It

The most common failure mode is not an underdeveloped BEP but one so lengthy and generic that no member of the project team reads beyond its first page. A small number of disciplined habits keep the document functional rather than decorative:

  • Draft it for the specific project rather than as a reusable template completed on autopilot. A BEP enumerating BIM uses the project will never require, copied from a previous job, signals to the entire team that the document itself carries little weight, a perception that becomes self-fulfilling once genuine questions arise mid-project.
  • Render the LOD/LOI matrix concrete rather than aspirational. "LOD 300 for structural elements at Stage 4" is verifiable. "High level of detail as appropriate" is not.
  • Assign a single owner responsible for keeping the document current. A BEP drafted once at kickoff and never revisited drifts out of alignment with how the project is actually being executed within a matter of months; someone, typically the BIM manager, must own its ongoing revision as real decisions are made.
  • Keep naming and folder conventions within the same document as the roles and process they govern, rather than dispersed across a separate standards manual that, in practice, nobody consults.

Common Mistakes

  • Treating the pre-appointment BEP as final. It constitutes a proposal, not an operating manual; the authoritative version is drafted after appointment, with the actual confirmed team.
  • An LOD matrix inconsistent with contractual requirements. Where the EIR specifies a level of detail the BEP's matrix does not, in fact, commit to, that discrepancy surfaces later as a formal dispute, not a rounding error.
  • No designated owner for the CDE itself. Absent a party responsible for enforcing the folder structure and naming convention, a CDE degrades into the same disorganization it was intended to replace, now merely relocated to a cloud login.
  • Omitting the software and version section on the assumption that "everyone already knows." Consultants and subcontractors joining mid-project do not, and this is precisely the kind of unstated assumption that produces an IFC export no other party's software can correctly open.

Where This Fits

Authoring a BEP is typically the responsibility of the BIM manager, the role tasked with setting a project's information standards rather than executing its day-to-day coordination. Where day-to-day coordination, the domain of the BIM coordinator, centers on federated-model checks and clash resolution, drafting a BEP demands the strategic view: translating a client's information requirements into an operating framework the rest of the team can follow, then owning that framework as real decisions are made through the life of the project. It rewards the same discipline that good family-building and clean worksharing setup reward: doing the unglamorous structural work up front so the rest of the project doesn't have to improvise its own standards halfway through.

For those building toward a BIM coordination or management role who wish to practice producing this kind of deliverable rather than simply read about it, that is precisely what our courses are designed to teach.