BIM Execution Plan (BEP): The Two Types, Every Section, and How to Tell If Yours Is Weak

A BIM Execution Plan is the document that sets out how a project will produce, manage and exchange its information. Under ISO 19650 there are two of them, produced at different moments by different parties for different purposes — and the distinction decides whether the document is a promise or a rulebook. This guide covers both types, every section a complete BEP contains, why a BEP copied from a template is a dead document, what it has to say about authority submission in the Gulf, and ten tests that tell you whether yours is actually working.

What Is a BIM Execution Plan?

A BIM Execution Plan (BEP) sets out how the information requirements on a project will be managed and delivered by all the parties involved. It is produced by the supply chain in response to the appointing party’s Exchange Information Requirements, and it details the responsibilities and deliverables of each stakeholder along with the agreed processes for sharing and exchanging information through every stage.

Put simply: the EIR asks, and the BIM Execution Plan answers. The client states what information they need and when; the delivery team states how it will be produced, by whom, to what standard, in what environment, and to what schedule.

The concept predates ISO 19650 — it was defined in the UK’s PAS 1192-2 as a plan prepared by suppliers explaining how the information modelling aspects of a project would be carried out. What ISO 19650 added was structure, and specifically the split into two distinct documents.

The Two Types of BIM Execution Plan

This is the distinction that most discussion of BEPs skips, and it changes what the document is for.

The pre-appointment BEP

This is the centrepiece of an ISO 19650 tender response, and it is not a formality or a box-ticking exercise. It is where a prospective delivery team demonstrates three things: that they understand the Exchange Information Requirements, that they have the capability and capacity to deliver against them, and that they have a coherent strategy for managing information across the project.

A pre-appointment BEP that reads as a generic capability statement rather than a specific response to this client’s requirements tells the appointing party exactly what they need to know — and it is not flattering.

The delivery team BEP

After appointment, the lead appointed party confirms the delivery team’s BEP in agreement with each appointed party. That phrase carries weight: this is not a document the lead issues and others receive. It is negotiated and agreed, because each task team has to be able to actually do what it commits to.

The journey between the two is the whole point: the BEP goes from a tender promise to the document that governs construction. If the delivery team BEP is simply the pre-appointment BEP with a new date on it, the agreement step never happened.

A BIM Execution Plan Responds to the EIR

The single most useful rule in this subject, and the one that separates a working BEP from an expensive PDF.

Published guidance is explicit: the BEP should reflect and respond to the Exchange Information Requirements, and therefore any section that does not correlate to the information requirements, to the information management processes, or to project-specific information should not be there.

Read that as an instruction and it changes how you write the document. A BEP is not a demonstration of BIM knowledge. It is an answer to a specific set of questions the client asked. Sections that exist because the template had them — a page on the history of BIM, a generic software list, a description of clash detection in the abstract — are not neutral padding. They dilute the document and signal that nobody read the EIR closely.

Every Section of a BIM Execution Plan

Contents vary with the project and the client, but a complete BIM Execution Plan aligned to ISO 19650-2 covers this ground.

Two sections in that list are routinely missing entirely from BEPs in practice: information security and training. The first matters on government, utility, healthcare and critical infrastructure work. The second matters because a BEP committing a team to a workflow nobody has been trained on is a commitment to a failure.

Roles and the Information Management Function

The BIM Execution Plan names who does what, and ISO 19650 is specific that information management is a function to be performed rather than automatically a job title.

• Appointing party — the client, who issues the information requirements and authorises information for use.
• Lead appointed party — typically the lead designer or main contractor, who establishes the BEP and coordinates the delivery team.
• Appointed parties — each consultant, subcontractor or specialist producing information.
• Task teams — the working units within appointed parties who produce information containers.

The BEP should include an information management function schedule showing who performs each function, and the delivery team directory showing the hierarchy between task teams. Where a role is named without a named person and a named deputy, it will be unowned within a month.

Standards, Naming and Classification

The BIM Execution Plan fixes the conventions before production starts, because retrofitting them across a completed container set is days of work with no design value.

• Which standards apply — the ISO 19650 parts, any national guidance, the authority’s submission requirements, and the client or master developer standard.
• Which prevails on conflict. On Gulf projects a client standard, a municipal submission guide and a national annex can all say different things about naming. The BEP is where that is resolved, in writing, before anyone uploads anything.
• The container identifier structure — the coded fields and their permitted values.
• Revision and status codes, with their meanings stated rather than assumed.
• The classification system, applied consistently across all disciplines.

Our guide to ISO 19650 and BIM standards covers the layered stack of requirements and how to read it.

The CDE and Status Codes

The BEP defines the common data environment: which platform, how the four information states are configured, who has permission at each state, and how information moves between them through approval and authorisation.

Three questions the BEP should answer explicitly, because they cause disputes when left open:

• Who hosts it, who pays, and for how long after completion.
• Who owns the data and the intellectual property in the models.
• What happens at handover and on early termination — export format, archive transfer, continuing access.

Our guide to the common data environment covers the four states, the three gates and the hosting and ownership questions in detail.

Level of Development and Level of Information Need

The BEP states how much information each element must carry at each milestone, and for what purpose.

Two vocabularies are in use and both appear in Gulf projects. The LOD scale from 100 to 500 describes how developed and reliable an element is. Level of Information Need under ISO 19650 is purpose-driven — it asks what the information is for and specifies exactly the geometry and data needed to serve that, and no more.

Whichever the project uses, the BEP should express it as a matrix rather than a single number, because a project-wide “LOD 350” is not a specification. Our guide to BIM levels of development covers what each level supports and where the distinction between 300 and 350 becomes expensive.

Coordination Process and Cadence

The BIM Execution Plan defines how coordination actually runs, and vagueness here produces the most visible failures on site.

• Federation strategy — which models federate, how often, and who owns the federated file.
• The clash test matrix, discipline pairs in priority order, with tolerances per pair.
• Meeting cadence and the model submission day, fixed and published.
• Issue management — classification, ownership rules, escalation and closure.
• The movement hierarchy — which system moves when two conflict, so meetings resolve rather than negotiate.
• Exit criteria — what “coordinated” means and who signs it off.

Our guide to BIM coordination covers the seven-step cycle, the model intake checklist and a workable meeting agenda.

TIDP and MIDP

Two acronyms that appear in every BEP template and are understood in surprisingly few.

The value is in the consolidation. Individually, every TIDP looks achievable. Combined into an MIDP, the conflicts appear — two teams depending on the same input on the same date, or a deliverable due before the information it needs exists. That is the point of building it, and it is why an MIDP assembled after the deadlines are already set is a record rather than a plan.

The BIM Execution Plan and Gulf Authority Submission

In most markets a BEP is an internal discipline. In Saudi Arabia and the UAE it increasingly has an external consequence, and this is the section most published BEP guidance omits entirely.

Dubai

Dubai Municipality has required BIM on defined categories of project since 2013, and a circular issued in October 2023 introduced BIM model submission for new building permits with IFC as the format, taking effect from the start of 2024. When the model is the submission, the BEP’s decisions about classification, naming, property sets and export configuration stop being internal preferences and become permit conditions.

Abu Dhabi

Abu Dhabi Municipality publishes CAD and BIM submission requirements covering naming conventions, coordinate systems and file formats, with compliance requirements referencing ISO 19650. A separate model quality document addresses naming standards, model coordination and clash detection protocols. That means the coordination process defined in your BEP is being measured against a published expectation, not only against your own standard.

Saudi Arabia

Requirements are predominantly driven by client and programme. Large developers and giga-project programmes routinely specify information requirements and BEPs contractually, and those specifications are frequently more demanding than any municipal requirement.

What the BEP should therefore contain

• The authority submission requirement named explicitly, with its current edition.
• The export configuration that satisfies it — IFC version, classification mapping, property sets.
• An export testing schedule. Test the authority export in the first weeks and at every milestone, not the week before submission.
• Who owns the submission and who verifies it before it goes.

Software Versions on Multi-Party Projects

An operational decision that belongs in the BEP and is frequently left out until it causes a problem.

Revit file upgrades are one-way. A model saved in a newer version cannot be opened in an older one, with no downgrade path. On a project with five consultants, that single fact makes version alignment a contractual matter rather than an individual preference.

The BEP should state:

• The software and version every party will use, for the duration.
• The upgrade protocol — who decides, how much notice, what the cut-over looks like, and who tests add-ins first.
• The exchange format where versions differ, which is normally IFC and is version-independent.
• Add-in and script dependencies that must be tested before any upgrade.

Our guide to what’s new in Revit 2027 covers the compatibility problem and an upgrade decision framework in detail.

How to Tell If Your BIM Execution Plan Is Weak

Every BIM Execution Plan looks complete. These ten tests distinguish the ones that govern a project from the ones that sit in a folder.

1. Can you trace every EIR requirement to an answer in it? If not, the gaps will surface as questions later.
2. Would deleting the project name make it obviously generic? A BEP that could belong to any project answers no client’s requirements.
3. Is every role assigned to a named person with a named deputy? Roles assigned to companies are unowned.
4. Does it state which standard prevails when two conflict? If not, someone will decide that under time pressure, alone.
5. Is the LOD expressed as a matrix rather than a single number? A project-wide LOD is not a specification.
6. Does it define what “coordinated” means and who signs it off? Without an exit criterion, coordination ends when the programme says so.
7. Does the MIDP exist, and was it built before the milestone dates were fixed? Assembled afterwards, it is a record rather than a plan.
8. Does it name the authority submission requirement and its edition? On Gulf projects, an unnamed submission requirement is an unmanaged risk.
9. Is there an export testing schedule with dates? Untested exports fail at submission with no time to fix them.
10. Has every appointed party actually agreed to it? Under ISO 19650-2 the delivery team BEP is confirmed in agreement with each appointed party. A document issued rather than agreed has skipped the step that makes it binding.

Seven BIM Execution Plan Failures

Frequently Asked Questions

Conclusion

A BIM Execution Plan fails in one of two ways. Either it is generic — a template with a project name on it, answering requirements nobody read. Or it is complete and unagreed — a thorough document the lead party issued and the task teams never committed to.

Both are avoidable with the same discipline: write the BEP as an answer to the EIR, delete anything that traces to neither a requirement nor a project fact, and confirm it in agreement with each appointed party rather than issuing it. On projects in Saudi Arabia and the UAE, add one more section that most guidance omits — name the authority submission requirement, define the export configuration that satisfies it, and schedule the export test for week one rather than the week before you submit.