Table of Contents
A BIM execution plan (BEP) is the document that tells everyone on a project exactly how models get built, checked, shared, and handed over who owns which model, at what level of detail, in what software, by what date. Without one, coordination happens by accident: clashes get found on site instead of in the model, and nobody agrees on whose model is “the truth.” Under ISO 19650, the BEP is the delivery team’s formal answer to the client’s information requirements, and it’s produced in two stages once at tender and again after appointment. Below is a working BIM execution plan services breakdown, section by section, plus a free BEP template you can adapt today.
What Is a BIM Execution Plan?
Strip away the acronyms, and a BIM execution plan is a project rulebook for information. It answers four questions: who models what, to what standard, using which tools, and how it all gets checked before anyone relies on it.
Think of it as the difference between a construction site with a shared, agreed set of drawings and one where three subcontractors are each working from their own version. The BEP is what prevents the second scenario. It’s written by the delivery team (the architect, main contractor, or BIM manager acting as lead appointed party), reviewed and confirmed with the client, and then used as the working reference for the life of the project.
It’s not a marketing document and it’s not a generic BIM policy statement copied from the last job. A BEP that says “the team will follow BIM best practices” is not a BEP — it’s a placeholder. A real one names software versions, naming conventions, model owners, and delivery dates.
Why You Need a BEP (Even on Small Projects)
Teams often assume a BEP is only for major infrastructure jobs with dozens of consultants. That’s backwards. Small projects are where BEPs get skipped most often and where the cost of skipping one is proportionally higher, because there’s no dedicated coordination manager to catch problems informally.
Take a real scenario: a 12-unit residential renovation with one architect, one structural engineer, and one MEP consultant. No BEP means each consultant picks their own origin point, their own file-naming pattern, and their own model version of “current.” Three weeks before submission, someone discovers the structural model was built off a different survey than the architectural one, and every wall dimension is off by 40mm. A two-page BEP — shared origin point, shared naming convention, one CDE folder would have taken an afternoon to write and would have caught that in week one, not week eleven.
On larger projects, the stakes compound. A 40-storey mixed-use tower with six subcontractor disciplines feeding models into a shared CDE has hundreds of potential clash points between structure, MEP risers, and façade systems. Without a BEP defining review cycles and clash tolerances, BIM coordination services become reactive firefighting instead of a scheduled process.
BEP vs PxP vs EIR: Clearing Up the Confusion
These three terms get used interchangeably by people who shouldn’t use them interchangeably. Here’s what actually separates them.
Term | What it is | Who writes it | When |
EIR (Exchange Information Requirements) | The client’s list of what information they need and when | Appointing party (client) | Before tender |
BEP (BIM Execution Plan) | The delivery team’s response to the EIR — how they’ll deliver it | Lead appointed party / delivery team | Tender stage and post-appointment |
PxP (Project Execution Plan) | The original US term (Penn State CIC framework) for essentially the same concept as a BEP, often used on non-ISO-19650 projects | Delivery team | Project start |
The short version: the EIR is the ask, the BEP is the answer. “PxP” is largely a legacy or US-market label for the same document ISO 19650 calls a BEP you’ll see it on projects that predate ISO 19650 adoption or run under older US-based BIM frameworks. If a client’s contract references both, ask which framework governs; don’t assume they’re describing two separate deliverables.
Pre-Appointment BEP vs Post-Appointment (Project) BEP
ISO 19650 splits the BEP into two distinct documents, and mixing them up is one of the most common early mistakes.
Pre-appointment BEP is submitted with your tender, before you’ve won the work. It’s a capability statement: it shows the client you understand their EIR and have the resourcing, software, and experience to deliver it. It’s written by the prospective delivery team usually the BIM manager or information manager candidate and it stays fairly high-level, because you don’t yet know your final subcontractor list or exact resourcing.
Post-appointment BEP (sometimes called the project or delivery BEP) is produced once you’ve been awarded the contract. This is the live, detailed, operational document the one that actually governs the job. It names real people, real software versions, real delivery milestones tied to the master information delivery plan (MIDP), and it gets updated as the project evolves. If the pre-appointment BEP is your pitch, the post-appointment BEP is your contract.
A mistake we see constantly: teams write a strong pre-appointment BEP to win the bid, then never meaningfully update it after award. Six months in, the “BEP” on file still describes intentions from the tender stage instead of what the team is actually doing. That gap is where disputes start.
Pre-Appointment BEP vs Post-Appointment (Project) BEP
A BEP isn’t a form you fill in once. Each section should answer a specific operational question. Here’s what each one actually needs to do.
Project information and goals. Basic project identifiers, plus the specific BIM uses this project needs — design authoring, clash detection, 4D scheduling, 5D quantity take-off, or FM handover. Don’t list every possible BIM use case; list only the ones this project will actually use.
Roles and responsibilities. Names, not just titles. Who is the information manager? Who owns the architectural model? Who signs off model approval before it moves to “shared” status in the CDE? A responsibility matrix (RACI-style) works better here than prose.
Level of information need. This defines how detailed each model element needs to be at each project stage — geometry, and the data attached to it. Getting this wrong is expensive: over-modeling wastes hours nobody will use, under-modeling means the model can’t answer the questions it’s meant to answer. This section should reference the level of information need for each discipline and stage, and many teams still map this against the older BIM Level of Development, from LOD 100 to LOD 500 scale for clarity with clients less familiar with ISO 19650 terminology.
Common Data Environment (CDE) setup. Which platform, what the folder structure looks like, how files move through Work in Progress → Shared → Published → Archive states, and who has permission to move them. This is also where you define BIM collaboration and coordination techniques — federation frequency, model check-in schedules, and version control rules.
Coordination and clash detection protocol. How often models federate, what tolerance counts as a hard clash versus a soft clash, who triages the clash list, and what the resolution turnaround time is. This section should spell out clash detection and coordination workflows in enough detail that a new team member could run a coordination meeting from it alone — because how clash detection prevents costly construction errors depends entirely on catching issues before fabrication, not after.
File naming and standards. The naming convention (usually aligned to ISO 19650’s field structure), classification systems, coordinate systems, and units. Get this wrong and every downstream automation — quantity extraction, scheduling links, FM data — breaks.
Quantity and scheduling data. If the project uses models for quantity take-off and BOQ services, the BEP needs to state which elements carry quantity data, at what stage that data becomes reliable, and how it ties into project planning and scheduling for 4D sequencing.
Asset and FM handover data. What happens to the model after practical completion. This is where COBie standards for facility management get defined — which asset data fields the FM team actually needs, and who’s responsible for populating them before handover, not scrambling to backfill them after.
Training and support requirements. What software competency the project assumes, and what happens when a subcontractor’s team can’t meet it. This section is skipped constantly and causes real delays when a smaller trade partner shows up without the modeling capability the BEP assumed.
Who Is Responsible for Writing and Maintaining the BEP
The lead appointed party is contractually responsible for producing the BEP usually the main contractor on a design-build job, or the lead designer on a design-bid-build project. In practice, the actual authoring is done by the BIM manager or information manager, often in consultation with each task team’s own BIM lead.
But “writing” and “maintaining” are different jobs. Writing happens once (twice, counting the pre- and post-appointment versions). Maintaining is continuous the BEP should be a living document that gets revised whenever scope, team composition, or delivery milestones change. If your BEP hasn’t been touched since kickoff and you’re six months into construction, it’s no longer describing your project.
How to Create Your First BEP — Step-by-Step
- Start with the EIR. Read it line by line. Every requirement in the EIR needs a corresponding answer somewhere in your BEP — if the client asked for COBie data at handover and your BEP doesn’t mention it, that’s a gap that will surface at the worst possible time.
- Map your team’s actual capability. Don’t write aspirational commitments. If your structural engineer has never worked in a shared CDE before, your BEP needs to account for that with extra training time, not pretend it away.
- Draft the pre-appointment version first, focused on demonstrating capability at the strategic level — team structure, software stack, relevant project experience.
- After award, expand it into the post-appointment BEP. Add real names, real delivery dates tied to the MIDP, and detailed technical workflows.
- Run it past every task team lead before finalizing. A BEP written in isolation by one BIM manager and never reviewed by the MEP or structural leads will miss discipline-specific realities.
- Set a review cadence. Monthly is typical on active construction projects; align it with your regular coordination meetings so updates aren’t a separate administrative task.
- Version and archive every revision in the CDE itself, so there’s never ambiguity about which BEP version governs a given decision.
Following broader BIM implementation best practices at each of these steps keeps the BEP grounded in what the team can actually deliver, not what looks good in a tender document.
Common Mistakes That Make a BEP Useless in Practice
Copy-pasting a template without adapting the specifics. Templates are a starting structure, not a finished document. A BEP that still references “the appointing party” in the abstract, with no actual project details filled in, tells the coordination team nothing.
Writing it once and never updating it. This is the single most common failure. Scope changes, a subcontractor gets replaced, the CDE migrates to a new platform — and the BEP still describes the original kickoff assumptions eight months later.
Making it too long to actually use. We’ve seen 90-page BEPs that nobody on the project has read past page 4. Length isn’t rigor. A BEP that a site-based BIM coordinator can’t reference quickly during a live clash meeting has failed at its job, regardless of how thorough it looks.
No named accountability. “The project team will ensure model quality” isn’t a responsibility — it’s a wish. Every deliverable in the BEP needs a named owner and a date.
Ignoring smaller subcontractors’ actual capability. A BEP that assumes every trade partner has the same modeling maturity as the lead designer sets up predictable failure points. Address capability gaps explicitly, with training or simplified deliverables, rather than hoping they resolve themselves.
Treating LOD/LOI as a single number for the whole project. Different elements need different levels of detail at different stages. A BEP that says “all elements at LOD 300” for the entire design phase either over-specifies simple elements or under-specifies complex ones.
Free BIM Execution Plan Template — Download
The template includes both a pre-appointment and post-appointment BEP structure, pre-built section headers matching the breakdown above, a responsibility matrix you can populate directly, and a CDE folder-naming worksheet aligned to ISO 19650 conventions. It’s built as a working document, not a sample to admire replace every bracketed placeholder with your actual project data before your first coordination meeting. If you’d rather have it built out for your specific project scope, BIM consulting services can adapt the template to your EIR directly.
A complete BEP includes project goals and BIM uses, named roles and responsibilities, level of information need by stage and discipline, CDE setup and file states, coordination and clash detection protocols, naming and classification standards, quantity and scheduling data requirements, and asset/FM handover data requirements.
A BEP is the ISO 19650 term for the delivery team’s response to a client’s information requirements. PxP (Project Execution Plan) is the earlier US-originated term for essentially the same document, most often seen on projects that don’t formally follow ISO 19650. The content overlaps heavily; the terminology depends on which framework the project references.
The lead appointed party is contractually responsible for the BEP, but the actual drafting is typically done by the BIM manager or information manager, with input from each task team’s discipline lead. The client (appointing party) reviews and confirms it rather than authoring it.
Long enough to answer every requirement in the EIR with specific, named commitments and no longer. Small projects can run to 5-10 pages; large multi-discipline projects with complex CDE and FM requirements often run 30-50 pages. Length should track project complexity, not effort spent padding it.
The EIR (Exchange Information Requirements) is written by the client and states what information they need. The BEP is written by the delivery team in response, stating how they’ll deliver it. One is the ask; the other is the answer.
Yes the scale changes, not the necessity. A small project’s BEP can be a few pages covering shared origin points, naming conventions, and a single CDE folder structure. Skipping it entirely is what causes coordination errors that are disproportionately costly to fix relative to the project’s size.
For a 12-unit residential renovation with three consultants, a workable BEP would fit on two pages: shared coordinate origin and survey source, one agreed file-naming convention, a single shared CDE folder with three subfolders (WIP, Shared, Published), a weekly model-check cadence, and named model owners for architectural, structural, and MEP.
No. A BEP template is the blank structure — the section headers and formatting. A BIM execution plan is the completed, project-specific document with your actual team, standards, and delivery dates filled in. A template only becomes a real BEP once every placeholder reflects your project.
Next Step
Pull up your client’s EIR right now and check whether you can answer every line item with a named person and a date. If you can’t, that’s exactly where to start editing the template above not at page one, but at the gaps the EIR actually asks about.