A BIM Execution Plan (BEP) is the governing document for how BIM will be implemented on a specific project. It defines who does what, in which software, to what standard, and by when. Without a BEP, BIM on a project becomes a collection of individual habits rather than a coordinated workflow. Writing a good one takes a few hours and saves weeks of confusion.

Pre-Appointment vs Post-Appointment BEP

Under ISO 19650, there are two versions. The pre-appointment BEP is submitted during tender — it demonstrates the bidding team’s capability and approach to meet the client’s Exchange Information Requirements (EIR). It is necessarily high-level since the full team is not yet appointed. The post-appointment BEP is the live working document, developed in detail once the team is confirmed and updated throughout the project as decisions are made.

What Goes in a BEP

Project information: Name, number, client, key dates, and a list of all parties involved with their roles and BIM responsibilities.

Standards and methods: Which version of which standards apply (ISO 19650, local standards), the agreed naming convention, coordinate system, and shared origin point.

Software and formats: Which authoring tools each discipline uses, which exchange formats are required (IFC version, DWG, NWC), and any format conversion responsibilities.

Model structure: How the model is broken down — by level, zone, discipline, or building system. Which elements each party is responsible for modelling.

Level of Information Need (LOIN): What geometric detail and non-graphical data is required at each project stage. This replaces the older LOD table and is more precise about what information each element must carry at each milestone.

Common Data Environment: Which platform, the folder structure, the naming convention in detail, and the four-state workflow (WIP → Shared → Published → Archived).

Coordination process: Clash detection schedule, who runs it, which software, how clashes are assigned and tracked, and what the escalation path is for unresolved clashes.

Delivery milestones: The information delivery plan — which models and documents are due at each stage gate, who approves them, and what the review period is.

Roles and responsibilities: Named individuals for BIM Manager, BIM Coordinator, and information author roles. Their specific responsibilities and decision-making authority.

Practical Tips for Writing One

Start from a template — most BIM software vendors and industry bodies publish free BEP templates. Fill in the project-specific sections rather than writing from a blank page. Keep it concise: a BEP that is 80 pages long will not be read. The sections on naming convention, CDE workflow, and coordination schedule are the ones people actually reference day to day — make those clear and specific. Everything else can be brief.

Hold a BEP kick-off meeting with all discipline leads before the document is finalised. The BEP only works if everyone has agreed to it — a document written in isolation by the BIM manager and circulated for signature is not the same as one developed collaboratively.

Keeping It Live

A BEP published at project start and never updated is only marginally better than no BEP. Schedule a review at each project stage gate. Update the software versions, the team members, and the coordination schedule as the project evolves. Version-control the BEP itself in the CDE so there is always a clear record of what was agreed and when.

Conclusion

A BEP is project governance made practical. It is the agreement that lets a multi-disciplinary team work from a shared model without constantly arguing about whose version is current, who is responsible for what, and how decisions get made. Write it early, write it collaboratively, and keep it updated — and it earns its cost back within the first coordination meeting.