BIM execution plan basics, without the boilerplate

What a BIM execution plan is

A BIM execution plan, usually shortened to BEP, is an agreement among the project team about how information will be produced and exchanged. It answers practical questions: who models what, in which software and version, to what level of detail, on what coordinate system, shared how and how often, and checked by whom.

The BEP is not a contract on its own, but it often sits alongside one, and the client's requirements may make it a contractual deliverable. It is also not a firm's internal standard, although it will reference one. Think of it as the project-specific layer that connects the client's needs to each team's way of working.

Where the BEP fits

Terminology varies by region and framework, but the logic is similar:

• The client states requirements. Under ISO 19650 these are expressed as information requirements, such as exchange information requirements for a specific appointment. Elsewhere they may sit in a BIM addendum, a contract exhibit or the scope of services.
• The delivery team responds with a plan. In the ISO 19650 process there is typically a pre-appointment BEP that shows how the team would meet the requirements, and a more detailed BEP once appointed.
• Teams follow their own standards for everything the BEP does not override.

In North America, many teams draw on planning guidance such as the BIM Project Execution Planning Guide developed at Penn State, or on templates from industry bodies. Whatever framework you use, read the actual client documents first. A BEP that ignores the contract is worse than no BEP.

The sections most plans need

1. Project information and goals

Basic project data, plus a short list of what BIM is meant to achieve on this project. "Coordinate structure and services before construction" or "provide an asset data set for the owner's facility system" are goals. "Use BIM" is not.

2. BIM uses

The specific uses the team commits to, such as design authoring, coordination, quantity take-off, 4D sequencing or record modeling. Each use implies work, so include only uses that serve a stated goal and that someone has agreed to deliver.

3. Roles and responsibilities

Who is responsible for each model, who coordinates, who manages the shared environment and who approves information for sharing. Use roles, and keep a separate contact list that can change without reissuing the plan.

4. Model breakdown and responsibility matrix

Which party models which elements, at which stage, and to what level of development or information. This is often a table by element and stage. The LOD and LOI guide explains how to fill it in without promising more than you can deliver.

5. Software, versions and formats

The authoring tools and versions each party will use, and the exchange formats. Version alignment matters: mixing major releases of the same authoring tool can block file sharing. State whether exchanges use native files, IFC or both; see the IFC export basics guide.

6. Coordinates, units and levels

The shared coordinate system, survey point and project base point conventions, units, and the source of truth for levels and grids. Mistakes here are among the most disruptive in a federated project, so test them early with a simple exchange.

7. File naming, structure and the shared environment

How files are named, how models are split, where they are stored and how information moves between work-in-progress, shared, published and archived states. If the client specifies a common data environment and naming standard, reference it rather than restating it.

8. Exchange schedule

When models are shared, in what format and to whom. A predictable rhythm, such as weekly coordination exchanges and milestone issues, helps every team plan.

9. Quality checks

What each party checks before sharing: model health, naming, coordinates, required parameters, clash tests. The model health checks guide suggests a practical set.

10. Coordination and issue management

How clashes and issues are identified, recorded, assigned and closed, and how often coordination meetings happen.

11. Deliverables and handover

What is delivered at each stage and at completion: drawings, models, data sets, and their formats. If the owner expects asset data, specify which data, in what structure and who verifies it.

Keep it short and specific

The most common BEP failure is length. Teams copy a large template, fill in the obvious fields and leave generic text everywhere else. Nobody reads it, so nobody follows it. A few habits help:

• Reference, do not repeat. Point to the client's standards and your firm's standards instead of copying them.
• Prefer tables to prose. Responsibilities, exchanges and checks are easier to follow as tables.
• Delete what does not apply. An empty section titled "Not used on this project" is clearer than paragraphs of generic text.
• Write decisions, not intentions. "Coordination models shared every Friday as IFC and native files" beats "Models will be shared regularly."

A simple process to write one

1. Read the requirements. List every BIM-related obligation in the client documents, with a reference to where it appears.
2. Hold a short kickoff workshop with each party's BIM lead. Agree goals, uses, responsibility split, software versions and coordinates.
3. Draft from a lean template. Fill in decisions from the workshop; flag open questions explicitly.
4. Test the exchange. Before production starts, have each party share a simple model to confirm coordinates, formats and naming actually work.
5. Agree and issue. Record who approved the plan and when.
6. Review at stage gates. Update the plan as the project moves through stages and as the team changes.

Keeping the plan alive

A BEP is most useful when the team consults it, which only happens if it stays accurate. Name one person, usually the lead appointed party's information manager or BIM lead, as the owner of the document. Keep a short change log at the front so people can see what changed since they last read it. When a coordination meeting makes a decision that affects the plan, such as a new exchange format or a change of responsibility, update the plan within the week and tell the team.

It also helps to separate stable content from volatile content. Goals, BIM uses and coordinate systems rarely change; contact lists, exchange dates and open questions change often. Keeping volatile items in appendices or linked registers means the core plan does not need reissuing for every update.

BEPs for small projects and small firms

Smaller projects still benefit from a plan, but it can be a few pages. At minimum, record the software and version, the coordinate approach, who models what, the exchange format and rhythm, and what each party checks before sharing. Even a one-page plan prevents the common early surprises: a consultant on a different version, models that do not align, or an owner expecting data nobody planned to provide.

If your firm is setting up its first BEP template, start with the firm-level standards the plan will reference. The BIM standards for small firms guide describes a right-sized starting point.

Common pitfalls

• Overpromising detail. Committing to a high level of development across all elements creates work nobody priced.
• Unclear data responsibility. If nobody owns a parameter, it will not be filled consistently.
• Untested coordinates. Discovering misalignment at the first coordination meeting costs time.
• Plan written by one party alone. A BEP that others have not agreed to is a wish list.
• Never updated. A plan that does not change as the project changes stops being useful within weeks.

Supporting tools

A BEP is easier to write when your firm already has a template, a kickoff checklist and clear ownership of standards. The Nova Foundation pack includes a project kickoff and information checklist designed for that early conversation. It is a planning aid, not a complete project BEP, and it does not replace the client's requirements or professional advice.

BEP checklist

• Client requirements listed with references.
• Goals and BIM uses, each with an owner.
• Roles, responsibility matrix and model breakdown.
• Software versions, formats, coordinates, units, levels and grids.
• Naming, storage and information states.
• Exchange schedule and pre-share checks.
• Coordination and issue process.
• Deliverables and handover data.
• Approval record and review points.