Most BIM Execution Plans are too long and too generic. They open with several pages describing what BIM is, restate software marketing copy, and then leave unresolved the handful of questions that will actually cause disputes: who owns the federated model, what coordinate system is authoritative, when models are exchanged, and what happens when a party misses an exchange.
A BEP is a working agreement, not a brochure. This guide covers the sections that earn their place.
Pre-contract and post-contract
Under ISO 19650, the BEP has two lives. The pre-appointment BEP is the delivery team's proposed approach, submitted in response to the appointing party's Exchange Information Requirements — it demonstrates capability and states intent. The post-appointment BEP is the confirmed plan, agreed after award, and it becomes the operative document.
Firms working outside ISO 19650 often produce a single document. That is workable, provided it is written after award with the actual team named.
Section 1 — Project information and roles
State the project, the parties, and the software environment precisely, including versions. "Revit 2025" and "Revit 2026" are not interchangeable across a project team, and version drift mid-project is a genuine cause of lost work.
Roles should name individuals, not organizations:
- Information Manager / BIM Manager — owns the plan and the common data environment
- BIM Coordinator per discipline — owns their model's compliance
- Model Element Authors — who models what, per the LOD table
- Clash coordinator — runs federation and issues reports
- Model acceptance authority — who signs off that a delivered model meets the plan
The last of these is omitted from most BEPs and is the one that determines whether the plan has teeth.
Section 2 — Coordinate system and units
This section should be short and absolutely unambiguous:
- Project base point and survey point, with real-world coordinates
- Rotation from true north
- Units and precision
- The authoritative source file from which all others acquire coordinates
- The procedure for publishing coordinates to new models
Coordinate misalignment is the most common single cause of failed federation, and it is entirely preventable at this stage.
Section 3 — Model structure and naming
Define how the project is divided: by discipline, by building, by level, by zone. State file size targets, because models that grow past a workable threshold slow every subsequent activity.
Naming conventions should follow a project-wide code — ISO 19650's fields for project, originator, volume, level, type, role and number, or a firm equivalent. What matters is that it is written down, applied to every file, and enforced at upload rather than corrected later.
Worksets, view templates, browser organization, and sheet numbering all belong here.
Section 4 — The LOD table
This is the substantive core of the plan. A single project-wide LOD statement is not usable. The table should list elements by a recognized breakdown structure, with a level of development and a named author at each project stage.
Include a column for model use — what each element is relied upon for. An element modeled for visualization carries different obligations than one modeled for quantity extraction or fabrication, and stating the use resolves most later arguments about adequacy.
Section 5 — Model uses
List the specific uses the model will support, and for each, name the responsible party and the required inputs:
- Design authoring
- Design coordination and clash avoidance
- Quantity takeoff and cost estimating
- 4D construction sequencing
- Energy and daylight analysis
- Prefabrication
- Asset information handover
Do not list uses the project will not actually pursue. Aspirational model uses commit the team to modeling effort that never gets used, and they undermine the credibility of the whole document.
Section 6 — Information exchange
Specify the mechanics, not the philosophy:
- The common data environment and its folder structure (Work in Progress, Shared, Published, Archive)
- Exchange frequency and the day and time of each
- Formats for each exchange — native, IFC with a named MVD, NWC, PDF
- Naming and revision coding for issued files
- The approval workflow moving a file from Work in Progress to Shared
- What happens if a party misses an exchange
Weekly exchange on a fixed day is the norm for design coordination; more frequent exchange is appropriate during intensive coordination periods.
Section 7 — The clash matrix
Include the full matrix of system pairs, tolerances, and priorities, the meeting cadence, the issue tracking platform, and the definition of each issue status. Also state the coordination zone sequence and its alignment with the construction program, since coordinating in an order unrelated to the build sequence is common and wasteful.
Section 8 — Quality control
Name the checks, their frequency, and who performs them:
- Model health check (warnings, unplaced elements, purge, audit) before every issue
- Standards compliance audit against the naming and workset conventions
- Coordinate verification
- Schedule reconciliation spot checks
- Deviation checks where existing conditions are modeled
State the threshold that constitutes rejection. A quality section without a rejection threshold is advisory.
Section 9 — Asset information and handover
If the project has an asset information requirement, define it here: the parameter schedule, the classification system, the format (COBie or an equivalent), the population responsibility per element, and the verification method. Handover requirements discovered late in a project are among the most expensive forms of rework in the entire BIM process.
Section 10 — Technology and interoperability
Short but consequential. State the software and version for every discipline, and the exchange formats between them. Where a discipline works in a different platform, name the translation route and who verifies that the translation was faithful — geometry loss and parameter loss in IFC exchange are routine and are discovered late unless someone is checking.
Also state hardware and performance expectations where models will be large, and the policy on version upgrades mid-project. Upgrading a project's authoring platform mid-delivery is occasionally necessary and always disruptive; the plan should say who authorises it and how the whole team is migrated together.
Section 11 — Risk and escalation
The section most BEPs omit and the one that determines whether the plan is enforceable. It should name:
- What happens when a party misses an exchange
- What happens when a delivered model fails the quality threshold
- Who escalates, to whom, and within what period
- How disputes about model adequacy are resolved, referencing the LOD table
- The consequence of persistent non-compliance
None of this needs to be adversarial. Stating it plainly at the outset is what allows a coordinator to act on a problem in week three rather than raising it in month four when it has become a schedule issue.
What to leave out
- Explanations of what BIM is
- Software feature descriptions
- Generic benefits statements
- Any process the team has no intention of following
Every unfollowed clause in a BEP reduces the authority of the clauses that matter.
Keeping it alive
A BEP written once and filed is a compliance artifact. A useful one is revisited at each stage gate, updated when the team or scope changes, and referenced in coordination meetings. Version it, date it, and record who approved each revision.
Reading a client's BEP before you sign
When the appointing party issues their own BEP or information requirements, read it for commitments rather than for description. The clauses worth finding before pricing:
The LOD or information level table. If it specifies LOD 400 across the design model, or asset data for every element, the modeling effort implied may be several times what the fee assumed.
Handover data requirements. Asset information obligations discovered late are among the most expensive forms of rework available, because population responsibility runs back through the whole delivery.
Model use list. Every listed use implies modeling effort. Energy analysis, 4D sequencing and fabrication support each carry real cost.
Exchange frequency and format. Daily exchange in a format your tools do not natively produce is a resourcing commitment.
Acceptance criteria and rejection thresholds. These determine how much internal QA you must budget.
Software and version mandates. A required platform you do not own is a licensing and training cost.
A thirty-minute read against this list, before fee submission, prevents the most common cause of unprofitable BIM appointments — which is not low fees but unpriced obligations buried in a document nobody read closely.
Frequently asked questions
How long should a BEP be? For a mid-size commercial project, 20 to 35 pages of substantive content, with the LOD table and clash matrix as appendices. Longer documents are usually padded.
Can a template be used? A template is a useful checklist of sections. The content — LOD table, coordinates, roles, matrix — must be project-specific or the document is inert.
Who writes it? The lead appointed party or delivery team, in consultation with each discipline lead, and formally accepted by the appointing party.
Related reading: LOD 100 to LOD 500 Explained: A Practical Reference · BIM Clash Detection: Building a Workflow That Actually Resolves Clashes
Vantage CAD Services works to client BIM Execution Plans and can assist in drafting project-specific BEPs, LOD tables, and clash matrices. Contact info@vantagecadservices.com or +1 (512) 543-0831.