A detailed guide to BIM Execution Plans, including purpose, pre-appointment and post-appointment use, responsibilities, information delivery, coordination, quality control, and handover.
A BIM Execution Plan, often shortened to BEP, is the project document that explains how BIM and information management will actually be carried out. It turns broad requirements into working rules: who produces information, what they produce, when they deliver it, how it is checked, how it is exchanged, and how the team will know whether the process is working.
A good BEP is not just a software list and it is not just a template with names filled in. It is a practical agreement for the project team. It should help a new team member understand the project information strategy without needing to guess from scattered emails, meeting notes, model files, and old standards documents.
In ISO 19650-style delivery, teams often distinguish between a pre-appointment BEP and a confirmed or post-appointment BEP. A pre-appointment BEP is normally part of the tender or appointment response. It explains how the prospective delivery team proposes to meet the appointing party's information requirements. After appointment, the BEP is confirmed and maintained as the team, tools, dates, responsibilities, and detailed delivery methods become clearer.
The most useful BEPs are living project documents. They should be controlled, updated when the delivery strategy changes, and reviewed at agreed points. A BEP that is prepared once and then forgotten usually becomes a compliance artifact rather than a working guide.
The BEP should begin with the purpose and scope of BIM on the project. This is where the team explains why BIM is being used and what value it is expected to create. The answer might include design coordination, quantity support, issue management, sequencing, energy analysis, asset handover, digital twin preparation, approvals, or a combination of these. Without a clear purpose, teams often over-model some information and under-deliver the information the client actually needs.
The plan should identify the appointing party, lead appointed party, appointed parties, task teams, information manager or BIM manager roles if used, design discipline leads, model authors, coordinators, reviewers, and approvers. Role names vary by market and contract, so the BEP should explain responsibilities in plain language instead of relying only on titles.
Responsibilities should be connected to deliverables. It is not enough to say that an architect, engineer, contractor, specialist, or supplier is responsible for BIM. The BEP should show which party creates each model, document, register, issue response, data drop, validation report, or handover dataset. It should also show who checks, accepts, or authorizes each item.
The BEP should describe the information requirements that drive delivery. These may include organizational information requirements, asset information requirements, project information requirements, exchange information requirements, employer's information requirements, or other client and project-specific requirements. The terminology can vary, but the practical question is the same: what information is needed, for what purpose, by whom, and at what point?
A strong BEP explains the planned BIM uses. Typical uses include design authoring, federation, clash detection, spatial coordination, visualization, design review, cost support, 4D sequencing, constructability review, procurement support, asset data capture, commissioning evidence, handover, and operations support. Each use should have an owner, required inputs, expected outputs, accepted formats, and success criteria.
The BEP should define information delivery milestones. This includes the dates or project stages when models, documents, schedules, registers, issue reports, validation outputs, and handover information are expected. It should also explain interim review points, not only final submissions. BIM quality is much easier to manage when problems are found at planned checks rather than at the final delivery gate.
The plan should state the model breakdown structure. This may include discipline models, zones, levels, buildings, systems, packages, worksets, federated models, coordination models, and handover models. The BEP should also explain whether the team will use one model, multiple discipline models, package models, temporary coordination models, or a combination.
A BEP should define model origin, coordinates, units, georeferencing approach, shared coordinates, level naming, grids, tolerances, and exchange expectations. These details sound technical, but they prevent practical failures. If models do not line up, if units are inconsistent, or if the agreed coordinate strategy is unclear, coordination becomes unreliable very quickly.
The plan should explain the level of information need. This means the amount of geometry, information, and documentation needed for each purpose and stage. The BEP should avoid vague phrases such as model to LOD 300 unless the project defines what that means. Better wording explains the required objects, properties, classifications, accuracy, geometry, documents, and acceptance checks for the specific exchange.
The BEP should document naming conventions. Names for files, models, drawings, documents, folders, views, revisions, issues, and exports should be predictable. Naming should help people find the current information container and understand discipline, originator, project, zone, level, type, role, number, status, revision, and purpose where those fields are relevant.
The plan should define status, suitability, and revision rules. Project information often moves through states such as work in progress, shared for coordination, shared for review, published for a specific purpose, accepted, archived, or superseded. The exact codes vary, but the BEP should make the meaning clear so that nobody treats draft information as approved information by accident.
The BEP should describe the common data environment process. This does not only mean a software folder. It means the rules for storing, naming, sharing, reviewing, accepting, publishing, archiving, and superseding information. The BEP should explain access rights, review workflows, approval gates, transmittals, metadata, audit trails, and what happens when information is rejected or returned for correction.
Interoperability belongs in the BEP. The team should state the authoring tools, coordination tools, viewers, model-checking tools, data tools, file formats, exchange formats, and versions that will be used. If IFC, BCF, COBie, PDF, DWG, native model files, spreadsheets, databases, or API exchanges are required, the BEP should explain when they are used and what each exchange is meant to achieve.
The plan should define model coordination and issue management. It should explain how often models are exchanged, who federates them, which checks are run, how clashes are grouped, what counts as a real issue, how issues are assigned, how decisions are recorded, and how resolution is confirmed. A clash report with thousands of unmanaged items is not a coordination process.
Quality control should be explicit. The BEP should state the checks that information authors perform before submission, the checks that coordinators perform during review, and the acceptance checks that the appointing party or lead appointed party may apply. Checks may include file naming, model location, classification, required properties, duplicate elements, model health, geometry scope, issue closure, drawing-model consistency, and handover data completeness.
The BEP should explain information security and access. Built-asset projects often include commercially sensitive, personal, safety-related, or security-sensitive information. The BEP should describe who can access what, how external parties are managed, how downloads and exports are controlled, and how archived information remains traceable.
The BEP should include change management. If project requirements change, if a new tool is adopted, if a model breakdown changes, if a data requirement is added, or if a milestone is revised, the BEP should explain how that change is proposed, reviewed, accepted, and communicated.
Handover should not be left to the end. The BEP should explain which asset information is needed for operation, when it starts being collected, who owns each field, how it is checked, and how final handover packages will be accepted. If the operator needs maintainable asset data, warranty data, commissioning evidence, manuals, locations, serial numbers, or system relationships, the project should plan for that early.
A BEP should also include assumptions, exclusions, and known risks. For example, the team may exclude temporary construction models from formal handover, identify a missing data source, note limited tool support for a target format, or flag that a supplier has not yet confirmed its information capability. These notes are not weaknesses; they make the plan honest.
Common BEP problems are easy to recognize. Some plans are too generic, so they do not guide daily work. Some are too technical, so decision makers cannot understand them. Some list deliverables without owners. Some define model detail without explaining the use case. Some mention open standards without defining the actual exchange. Some ignore handover until the project is nearly finished.
The practical connection to a workspace platform is simple: a BEP creates a lot of commitments that need to remain visible. Controlled records, task ownership, review dates, issue decisions, delivery registers, workflow maps, and handover evidence should stay close to the work instead of being scattered across private copies.
Useful references: NIBS Project BIM Execution Planning Standard ↗, UK BIM Framework ISO 19650 Guidance Part 2 ↗, ISO 19650-2:2018 ↗.
Related: ISO 19650 Explained in Plain Language, What Is a Common Data Environment?, BIM Roles and Responsibility Matrix, Information Requirements in BIM.
Source: WorkStudio Knowledge Hub. Published here from our WorkStudio article collection.
