BIM Execution Plan Guide: How to Write a BEP Teams Will Actually Follow
BIM Execution Plan guide for owners and project teams: what to include, LOD matrices, Scan to BIM, QA/QC gates, coordination rules, and EU/US delivery tips.
BimzstudioMay 4, 202613 min
BIM Execution PlanBEPISO 19650LODScan to BIMQA/QC
BIM Execution Plan Guide: Building a BEP That Controls Delivery, Not Just Documentation
A BIM Execution Plan (BEP) is supposed to be the project’s operating agreement for digital delivery: who models what, at which LOD, in what coordinates, with which exchanges, reviews, and acceptance tests. Too many BEPs are copied templates—long enough to impress at kickoff and ignored by week three. The result is predictable: mismatched coordinates, ambiguous LOD, unowned clash issues, and Scan to BIM scopes that were never defined tightly enough to QA.
This BIM Execution Plan guide shows how to write a BEP that working teams can follow, with practical sections for design-build and renovation projects across the EU and USA, including LOD matrices, coordination rules, and point cloud QA/QC gates.
A BEP only works when it answers the EIR with measurable methods.
Projects adopt BIM tools faster than they adopt BIM governance. A BEP exists to close that gap. It translates employer/client information requirements into day-to-day methods for authors, coordinators, surveyors, and contractors.
When the BEP is weak, teams experience:
Multiple “project north” stories and broken federations
Trade models that cannot be compared usefully
Arguments about whether LOD 300 includes hangers, slopes, or insulation
Point clouds delivered without acceptance criteria
Clash meetings without contractual teeth
Handover models unusable for facilities or future renovations
A strong BEP does not try to reinvent ISO standards or national frameworks. It makes them local, specific, and testable for this asset, this schedule, and these uses.
Why It Happens
Template theater
Organizations paste a prior BEP, change the project name, and assume alignment. Unique risks—occupied hospital, heritage fabric, industrial shutdown—never appear in the document.
Written by people who will not author models
If the BEP authors never open the authoring tools, exchange settings and performance strategies become fantasy.
No link to commercial terms
If the contract does not reference BEP obligations and payment milestones, compliance becomes optional.
Ambiguous existing-conditions scope
Renovations often bury Scan to BIM in a single sentence: “Contractor shall scan and model existing conditions.” Without LOD, tolerances, exclusions, and QA/QC, disputes are inevitable.
Living document fear
Teams either freeze the BEP too early or change it silently. Both destroy trust. Controlled revision is required.
Industry Examples (EU / USA)
European Union
Public and large private clients increasingly wrap BEPs inside ISO 19650 information management concepts: Exchange Information Requirements (EIR), responsibility matrices, and information containers.
Cross-border teams need explicit CRS, language, classification, and IFC exchange rules.
Industrial and infrastructure owners often require stronger survey/control statements in the BEP.
Heritage projects need measured-vs-interpreted rules and conservation constraints documented early.
United States
BEPs are common on design-build, healthcare, aviation, and large commercial work.
AIA/BIMForum LOD language frequently appears—useful only when accompanied by model element tables.
GCs often maintain coordination BEPs that subcontractors must follow for federation and clash gates.
Owner FM requirements may appear late; good BEPs capture handover information need early enough to influence modeling.
Despite framework differences, practical BEP content converges on roles, coordinates, LOD, exchanges, quality, and decision gates.
Technical Explanation
Name owners, formats, LOD matrices, and QA gates explicitly.
What a BEP must decide
A usable BEP answers at least these technical questions:
Uses: design coordination, prefabrication, estimating, FM, digital twin pathway, etc.
Roles/RACI: who authors, federates, approves, surveys, models existing conditions
Coordinates/units: survey point strategy, CRS, tolerances
Software and formats: native + exchange formats, versions
Model structure: worksets/containers, linking strategy, zoning
LOD / Level of Information Need: by category and milestone
Existing conditions: scan methods, QA/QC, Scan to BIM matrix
Appendices prevent the core BEP from becoming unreadable while still giving specialists the detail they need.
Sample Contract Hooks (Plain Language)
Without legal drafting pretensions, these ideas help owners and GCs connect BEPs to enforcement:
Model submissions that fail published naming/CRS/LOD preflight may be rejected without review.
Scan/point cloud deliverables are not accepted until the QA checklist is signed.
Zone prefabrication release requires documented clash gate completion for defined P0/P1 classes.
As-built/Scan to BIM milestones include deviation sampling reports as pay-app attachments.
BEP revisions require written approval and CDE announcement before they alter obligations.
Have counsel adapt language to your contract form. The principle is simple: if the BEP cannot affect payment or acceptance, it will not govern behavior.
BEP Anti-Patterns to Delete on Sight
“LOD 500 for all elements”
“Contractor shall coordinate all clashes” with no codes/SLAs
Software lists with no versions
Survey scope as a single sentence
RACI filled with company names only
Copy-pasted ISO clauses with no project method
Meeting schedules with no decision authority
Handover requirements invented at substantial completion
Delete or rewrite these before kickoff. They are how BEPs lose credibility.
Step-by-Step Solution
Step 1: Gather upstream requirements
Collect employer information requirements, contract BIM clauses, FM needs, and known site constraints.
Step 2: Run a BEP workshop (not a monologue)
Include design leads, trade BIM leads, survey/scan lead, GC coordinator, and owner representative.
Step 3: Lock coordinates and CDE first
Nothing else works if federation foundations are wrong.
Step 4: Build the LOD / information matrix
Attach intended uses to each milestone. Add Scan to BIM rows for existing categories.
Step 5: Define QA gates
Examples:
Cloud accepted before modeling
Pilot zone approved before full Scan to BIM production
Clash gate passed before prefab release
As-built deviation sample passed before handover
Step 6: Write coordination and issue SLAs
Include response times for P0/P1 issues.
Step 7: Publish v1.0 and train
Walk through a sample federation and a sample issue lifecycle.
Step 8: Pilot on one zone
Adjust tables based on reality; issue v1.1 with changelog.
Step 9: Enforce through submission rejection authority
If noncompliant models are accepted anyway, the BEP is dead.
Step 10: Closeout update
Record as-built methods, deviations, and lessons for the next project.
Case Study
Project: Multi-building U.S. campus lab upgrades + EU partner design team Initial state: Each firm carried its own BEP fragment; coordinates differed; existing tunnels were “to be scanned” with no tolerances.
Intervention:
Consolidated a single project BEP with bilingual appendix where needed
Adopted one CRS statement with diagrammed base points
Created LOD matrices separating new construction vs Scan to BIM existing
Added point cloud QA/QC acceptance checklist as a contractual gate
Defined clash codes and zone release criteria for tunnel interfaces
Required pilot Scan to BIM of one tunnel junction before mass production
Outcome: Federation stopped breaking, clash triage accelerated, and tunnel interface design decisions were made against verified geometry. The document succeeded because it was short where possible, strict where necessary, and enforced at gates.
Common Mistakes
100+ pages with no tables people can use weekly
LOD stated as a single number for the whole project
No existing-conditions chapter on renovations
Software list without exchange testing
Clash process described without issue ownership
Unnamed responsibilities (“BIM team shall…”)
Ignoring model performance strategy
No revision control
Copying ISO language without local methods
Forgetting handover/FM until demobilization
No acceptance tests for Scan to BIM tolerances
Writing a BEP after models are already diverging
Expert Tips
Put the three most project-specific risks on page one. Readers should feel this BEP was written for them.
Use screenshots of good vs bad model elements in an appendix to teach LOD faster than prose.
Create a one-page ‘field card’ summarizing CRS, naming, and publish rules.
Tie payment milestones to QA gates for scan acceptance and coordination release.
Include a decision tree for mobile vs static scanning if both are allowed.
Require a measured/inferred parameter on renovation elements.
Schedule a mid-project BEP health check.
Keep legal language in contracts and operational detail in the BEP—but cross-reference both.
Future Trends
Machine-readable BEPs feeding automated model checkers
Stronger ISO 19650 alignment with less paperwork duplication
Uncertainty and confidence metadata as standard BEP requirements for as-builts
Digital twin readiness clauses that still begin with verified BIM foundations
Automated compliance scoring on every CDE publish
Playbook BEPs by asset type (hospital, airport, plant) customized per project
The BEP of the future will be more executable and less ceremonial—but only if teams demand testable requirements today.
FAQ
1. What is a BIM Execution Plan?
A project-specific document defining how BIM will be delivered: roles, standards, coordinates, LOD/information need, exchanges, coordination, quality control, and handover methods.
2. Who should write the BEP?
Typically the delivery team in response to client requirements, with active input from discipline leads, the coordinator, and—on renovations—the survey/Scan to BIM lead. Owner review/approval is essential.
3. How is a BEP different from ISO 19650 documents?
ISO 19650 provides an information management framework (including requirements and planning concepts). A BEP (or delivery-team plan) makes those requirements concrete for the project’s tools, models, and gates. Naming varies by region; substance matters more than title.
4. What LOD information belongs in a BEP?
A category-by-milestone matrix, exclusions, intended uses, and—for Scan to BIM—tolerances and verification methods.
5. Should point cloud QA/QC be in the BEP?
Yes for existing-conditions projects. If acceptance criteria live only in a surveyor’s email, they will be contested later.
6. How long should a BEP be?
Long enough to remove ambiguity, short enough to be used. Many successful BEPs are modular: core rules + appendices.
7. When should the BEP be completed?
Before serious modeling and before scanning production on renovations. Pilot calibrations can trigger controlled revisions afterward.
8. What makes a BEP enforceable?
Contractual reference, submission rejection authority, milestone gates, and regular audits. A BEP without consequences is a suggestion.
Summary
This BIM Execution Plan guide reduces the BEP to what matters: testable agreements for uses, roles, coordinates, LOD, existing-conditions Scan to BIM, coordination, QA/QC, and handover. EU projects may wrap this in ISO-aligned information management; U.S. projects may emphasize BIMForum LOD and GC coordination gates. In both cases, success comes from specificity, training, and enforcement—not from template length.
If your BEP cannot tell a modeler whether a hanger is required, a surveyor whether a void is acceptable, or a coordinator whether a zone is releasable, it is not finished.
Put Scan to BIM and QA/QC into Your BEP with Bimzstudio
Bimzstudio helps owners and project teams define deliverable Scan to BIM scopes inside real project execution plans—LOD matrices, tolerance targets, point cloud acceptance checks, and coordination-ready modeling for EU and U.S. delivery. We focus on requirements you can verify, so BIM governance survives after kickoff.
If you are drafting or repairing a BEP for a renovation or complex MEP project, share your information requirements and existing-conditions risks. We will help you turn them into a practical, gate-driven Scan to BIM and modeling plan.
