BIM Execution Plan for International Construction Projects: A Project Manager’s Guide

What a BIM Execution Plan must accomplish

A BIM Execution Plan is the project-specific agreement for producing, exchanging, reviewing and accepting model-based information. According to the U.S. National BIM Standard BIM Execution Planning Standard, BEP development is foundational to successful BIM implementation and progresses from the owner’s requirements and request for proposal through a proposal BEP to the project BEP.

For a construction project manager, the BEP is valuable when it removes ambiguity. It should state what BIM will support, who is accountable, what information is exchanged, when it is required, how it is checked and which system holds the authoritative status. A generic document that lists software but does not govern decisions will not control delivery.

A six-step BEP development process

Begin with measurable project goals such as reducing spatial rework, validating the construction sequence, coordinating penetrations or delivering usable asset information. Select only the model uses that support those goals. Then map the process, define information exchanges and confirm the people, platforms, hardware, standards and training needed to execute it.

The NIBS Version 4 framework identifies five core planning steps: define goals, identify high-value model uses, design the process, define information exchanges and define infrastructure. For delivery, add a sixth management step: mobilize the team and audit whether the agreed process is actually working.

The project manager’s BEP checklist

The BEP should be concise enough to use and precise enough to enforce. Reference contractual documents rather than silently replacing them. Where the contract, appointment, employer or owner requirements use different terms, record the project definition and the governing precedence.

For each information exchange, state the purpose, originator, receiver, due date, model area, geometry and information need, format, checks and acceptance authority. This makes the exchange testable and allows the programme to include real review duration rather than assuming instant approval.

• Project BIM goals, model uses and success measures.
• Responsibility matrix, decision rights and escalation path.
• Model breakdown, coordinates, units, naming and classification.
• CDE workflow, status codes, revision rules and publication gates.
• Information exchange schedule aligned with design, procurement and construction.
• Clash, issue, constructability, quality and approval procedures.
• Security, access, intellectual-property and data-retention rules.
• Handover information, validation, training and close-out requirements.

BEP mobilisation checklist: test one information exchange before delivery

A completed template does not show that a delivery team can exchange usable information. Before relying on the plan, select one representative package and rehearse its path from production through review to the receiving team. The original checklist below turns that rehearsal into a record of responsibilities, evidence and unresolved decisions.

Pre-appointment and confirmed BEP: keep the stages clear

The UK BIM Framework’s Guidance Part E: Tendering and appointments, Edition 2 (February 2021), sections 4.2–4.4 distinguishes a tender-stage proposal from the delivery team’s confirmed plan. The plan is revisited when the appointment is finalised. Capability, capacity, mobilisation and information delivery planning also have supporting resources; a BEP is not a substitute for all of them.

For a UK project, identify the applicable appointment, information requirements and agreed standards first. Keep the BEP consistent with the responsibility matrix and task and master information delivery plans. The review aid here is an original management tool, not an ISO standard, an official template or a claim of certified compliance.

Six questions for a practical mobilisation review

1. Purpose and requirement. Identify the decision the exchange supports and link the applicable information requirement. Evidence to retain: The receiver confirms what must be delivered and why.
2. People and dates. Name the originator, checker, authoriser and receiver; allow time for review and correction. Evidence to retain: Each role and due date is agreed with the responsible team.
3. Scope and format. Record the package, model area, revision, units and agreed exchange format. Evidence to retain: The receiving application opens the intended information set without unexplained omissions.
4. Review and exceptions. Define a testable acceptance criterion, check method and route for unresolved findings. Evidence to retain: The reviewer records the checked revision, result and evidence; failures have an owner.
5. Information status. Agree how the reviewed package is identified and issued through the project common data environment. Evidence to retain: A site user can retrieve the intended revision and distinguish it from superseded information.
6. Correction and retest. Trial one correction and repeat the same check before relying on the workflow. Evidence to retain: The corrected source, reissued package and retest decision remain traceable.

Example: rehearse a coordinated services package

Hypothetical exercise: a team proposes issuing a coordinated ceiling-services package for a named floor. Before the first delivery, the originator identifies the model and drawing revisions, the checker samples the agreed interfaces, and the receiver opens the intended exchange in the receiving application. An omitted drawing reference or unresolved interface is recorded against that specific package, with an owner and a retest date. A successful file opening alone does not establish coordination or authorise installation.

Use the rehearsal to expose decisions still missing from the plan. If no one can identify who may authorise the package, record that gap rather than treating the exchange as accepted. Distinguish Not tested from Pass; a blank result is not evidence. After correction, repeat the relevant check and retain the new revision and reviewer’s decision. There is no universal pass percentage: agree the criteria for the package and its intended use before testing.

Download the BEP information-exchange review checklist (CSV)

The six-row checklist has blank project, responsibility, date, result and evidence fields. It contains no completed-project results. Use a spreadsheet to filter unresolved items; record the agreed review outcome and the exception owner rather than assuming that a completed row is an approval.

Connect the review to the work-package release workflow, the architectural model-validation checks and, where operational data is required, the receiving-system handover tests. See the other practical BIM templates for the corresponding delivery stages.

Make the BEP work across countries, contracts and disciplines

International teams often use the same words differently. Define terms such as shared, published, approved, level of information need, clash, issue, model manager and design responsibility. Record the project language, time zone, units, coordinate reference, holiday calendars and expected response times.

The BEP must also interface with local planning approvals, building regulations, professional appointments and data-location requirements. BIM coordination never overrides statutory approval or contractual design responsibility. The project manager should maintain a compliance map showing which authority, consultant or client role accepts each deliverable.

Govern the BEP as a live project control

Approve the initial project BEP during mobilization, then review it at defined stage gates and after major scope, organization or platform changes. Keep a decision log and record deviations. Short audits should sample file status, naming, model checks, issue closure, permissions and whether site teams can retrieve the current approved information.

A successful BEP becomes visible in everyday delivery: coordination meetings follow its workflow, the programme reflects its exchanges, approvals use its status rules and handover data is accumulated before close-out. That is the difference between a compliance document and a management system.

Control dashboard

Performance metrics for project managers