A BIM Execution Plan (BEP) should be treated as a working project agreement, not as a document prepared only for a tender submission. It sets out how information will be created, checked, shared and approved across the project team. When the BEP is clear before modelling starts, each discipline understands what it must deliver, when it must deliver it and how its information will be reviewed.
This guide sets out the practical decisions a project team should make before authoring models. The exact requirements should always be adjusted to the client appointment, project stage, contract, jurisdiction and agreed information requirements.
What is a BIM Execution Plan?
A BIM Execution Plan defines how the project team will produce, coordinate, review, exchange and manage BIM information throughout the agreed project stages. It translates the client’s information requirements into a delivery method that can be followed by architects, structural engineers, MEP engineers, contractors, specialist subcontractors and the wider design team.
Depending on the procurement and appointment process, a BEP may first be prepared as part of a tender response and later developed into an agreed project-delivery document following appointment. The post-appointment version should reflect the confirmed team, responsibilities, platforms, exchanges and deliverables.
A useful BEP defines the project objectives, model uses, responsibilities, naming rules, coordinates, exchange formats, review gates, issue workflows and quality checks. It should be specific enough for a coordinator to use during a live review, while remaining flexible enough to be updated as the project develops.
Why the BEP matters
Without an agreed plan, teams often make different assumptions about model origin, file naming, level of detail and issue ownership. The result is duplicated work, unreliable federations, late clashes and uncertainty over which information is current.
A practical BEP reduces this risk by making decisions visible. It gives the project manager a basis for planning information exchanges, gives discipline leads a clear scope and gives reviewers a consistent method for checking models. It also supports more predictable coordination meetings and clearer communication with the construction team.
Project information requirements
Start by recording what information is required, why it is required and when it is required. This normally includes the project stages, information exchanges, model uses, drawing outputs, schedules, asset data and the people who will approve each package.
- Define the intended uses for each model, such as design coordination, quantity review, construction planning or handover.
- Identify exchange milestones and the information that must be complete at each milestone.
- Record the required file formats, approval status, naming conventions and review responsibilities.
Do not specify a high level of detail simply because it sounds comprehensive. The requirement should be proportionate to the decision the information will support.
Roles and responsibilities
The BEP should name the client information manager, lead designer or lead appointed party, BIM manager, discipline leads, model authors, coordinators, reviewers and document controller. A responsibility matrix should show who authors, checks, approves, publishes and archives each information container.
Where a project includes a contractor or specialist subcontractor, their model and shop-drawing responsibilities should be stated early. The matrix should also identify who owns coordination issues and who confirms that a proposed resolution is acceptable from a design, construction and maintenance perspective.
The party responsible for federating models should also be identified, together with the limits of that role. Model federation and clash reporting do not transfer design responsibility from the originating discipline.
Model-authoring responsibilities
Each model-authoring team should know its geographic or discipline boundary, required model uses, expected content and review dates. The authoring team remains responsible for the accuracy and internal consistency of its own model; federation does not transfer that responsibility to the coordinator.
Define how links, shared coordinates, worksets, view templates, system classifications and key parameters will be managed. Agree who can edit shared content and who is responsible for resolving warnings or corrupted elements before an exchange.
Define whether models will be divided by building, zone, discipline, level, package or system. The segmentation strategy should consider authoring performance, coordination, exchange requirements and responsibility boundaries.
File naming and model structure
Use a naming convention that can be read by people and filtered by systems. A typical pattern may include project, originator, volume or system, level, type, role, number and status, but the actual convention must follow the project information standard.
Explain the expected folder structure and distinguish work-in-progress, shared, published and archived information. Model names, drawing names, issue codes and revision identifiers should be consistent across the CDE, transmittals and meeting records. Avoid informal filenames such as “final-new” or “latest-coordinated”.
Coordinates and shared positioning
Agree the survey reference, project base point, geographic location, north direction, units and coordinate system before modelling begins. Record who establishes the shared coordinates and how they will be checked when a model is linked or exported.
A simple validation view or coordinate-check report can prevent a major coordination failure. Test the process with a small sample exchange before all disciplines begin detailed authoring. For civil, marine or infrastructure work, record the horizontal and vertical datums that apply to the appointment.
Once shared coordinates have been approved, changes should be controlled and communicated formally because even a minor coordinate adjustment can invalidate federated reviews and downstream exchanges.
Level of Development requirements
Define the expected level of development and information for each discipline, element type and project stage. LOD is not a single number applied to every element; it should describe what can reasonably be relied on for a particular decision.
Where the appointment distinguishes between geometric development and information requirements, both should be defined separately rather than relying on a single LOD designation.
The BEP should state when geometry is indicative, when it is suitable for coordination, and when it is sufficiently developed for construction documentation or fabrication. LOD 500 should not be assumed automatically. As-built or asset information should be required only where it is part of the agreed handover scope and can be verified.
Common Data Environment
Specify the CDE platform, folder or container structure, permissions, approval states and audit trail. Everyone should understand how an author moves information from work-in-progress to shared review and then to published or contractual status.
Record how transmittals, comments, superseded files and approvals are retained. A CDE process is effective only when the project team uses it consistently; a technically capable platform does not replace clear rules.
The BEP should define the permitted suitability, review or approval statuses and explain which information may be used for coordination, construction, contractual reliance or reference only.
Access permissions, external sharing, download rights and the handling of sensitive project information should also be agreed.
Model-sharing frequency
Set exchange dates around design milestones and coordination needs rather than choosing a frequency in isolation. Weekly exchanges may be appropriate during intensive coordination, while early concept work may require less frequent formal publication.
Allow time for authors to complete internal checks before a federation. The BEP should also define what happens when a model misses an exchange date, including how the risk is recorded and communicated.
Clash-detection workflow
Describe how models are federated, which rules are applied and how results are reviewed. A useful workflow separates hard clashes, clearance issues, access and maintenance conflicts, design compliance issues and items that require a design decision rather than a geometric change.
The BEP should include or reference a clash matrix identifying which disciplines and systems are tested against each other, the applicable tolerance, the responsible reviewer and the project stage at which each test becomes relevant.
- Confirm that each discipline model is correctly positioned, named and internally checked.
- Federate the agreed models and run the approved rule sets for the current stage.
- Review results with discipline leads, group related issues and remove duplicate or invalid tests.
- Assign each accepted issue to an owner with a due date and a clear required response.
- Re-run the test after updates and close the issue only when the resolution is verified.
The BEP should record the software, tolerances, viewpoint conventions, issue statuses and meeting rhythm used for this process.
Issue tracking and closeout
Issue records should contain a unique reference, location, description, responsible party, priority, due date, status and supporting view or snapshot. Keep the wording factual and describe the impact on space, access, programme, cost or compliance where known.
Closeout requires evidence. A status change alone is not enough; the updated model, drawing or decision record should show how the issue was resolved. The BEP should state who verifies closure and how unresolved items are carried into the next stage.
QA/QC requirements
Define checks for model health, warnings, coordinates, naming, links, levels, grids, parameters, views, sheets, exports and drawing consistency. Separate author checks from independent review checks so that the same person is not the only control.
Set review gates before each formal exchange. A short checklist, signed or recorded in the CDE, is often more useful than a long list that no one completes. Where authority-facing documentation is required, include a review of drawing registers, revision history and interdisciplinary consistency.
Deliverables and exchange formats
List the outputs required at each milestone: native models, federated review files, IFC or other open exchanges where agreed, drawings, schedules, reports, issue registers and supporting calculations or specifications. Define who owns the export and how the receiving party confirms that the exchange opened correctly.
For construction support, distinguish coordination information from contractual or fabrication information. Do not imply that an exported model carries a higher contractual status than the appointment allows.
BEP governance and updates
The BEP should identify who owns the document, who may approve revisions and how updates are communicated. It should be reviewed whenever there is a significant change to the project team, scope, model structure, delivery stage, software environment, information requirements or exchange programme. Previous versions should remain traceable through the project’s document-control process.
BEP review checklist
- Are the information requirements and model uses clear for the current stage?
- Are authoring, checking, approval and issue-ownership responsibilities named?
- Are the CDE, naming rules, coordinates, units and exchange dates agreed?
- Are LOD and information requirements written by element and stage?
- Are clash rules, tolerances, issue statuses and closeout checks defined?
- Are deliverables, formats, revision controls and acceptance criteria listed?
- Is there a scheduled review point for updating the BEP when the project changes?
Common BEP mistakes
Common failures include copying a generic BEP without tailoring it, specifying LOD without information requirements, leaving coordinates until late design, listing software instead of responsibilities, and treating clash detection as a one-off report. Another frequent problem is publishing a model without an agreed status, revision or review record.
A BEP should also avoid promises that the project team cannot resource. A realistic exchange schedule and a clear escalation route are more valuable than an ambitious process that is not followed.
Conclusion
A well-structured BIM Execution Plan gives a multidisciplinary team a shared method for producing, reviewing and exchanging project information. It helps the team focus coordination effort on the decisions that matter, improves traceability and supports more reliable documentation as the design develops.
Review the BEP at each major stage and update it when scope, appointments, software or information requirements change. The plan should remain a live project control, not a static appendix.
Related services and resources
For related support, see BIM & Digital Engineering and the wider Technical Resources library. These references can be used alongside the project appointment, information requirements and agreed delivery standards.
Discuss Your BIM or Engineering Requirement
Trueform Engineering Consultants provides project-based BIM modelling, multidisciplinary coordination and technical engineering support for consultants and contractors. We would be pleased to review your project requirements and respond accordingly.