Skip to main content

// BIM Management

Writing a BIM execution plan that actually serves the project

Published on 12 May 2026 · 7 min read · CADatWORK Learning

Coordination meeting around a digital model

Most BIM execution plans (BEPs) we audit share the same flaw: they describe an intention, not a way of working. They list generic use cases, stack levels of detail and end with a naming annex nobody applies.

A useful BEP passes a simple test: on reading it, every party knows what they must deliver, in what form, by when, and how their delivery will be checked.

Start from use cases, never from tools

A BIM use case is formulated as a decision to be made: checking compliance of an area schedule, resolving a routing clash, pricing a work package, preparing operation. It is this use case that determines the data needed, and therefore the modelling effort.

As long as the use case isn't named, any level-of-detail requirement is arbitrary: you model too much where it doesn't matter and not enough where the decision is actually made.

Make every requirement verifiable

An uncontrollable requirement is a dead requirement. For each piece of data requested, the BEP must state the carrying object (which element), the exact property name, the unit, the expected value or list of admissible values, and the milestone from which it is required.

Written this way, the requirement becomes translatable into a set of validation rules — in Solibri, in Simplebim or via an IDS file. Quality control stops being a case-by-case visual inspection.

  • Clearly typed carrying object (wall, slab, equipment, space)
  • Explicit property name and PSet, with no spelling variants
  • Imposed unit and value format
  • Requirement milestone, distinct from the graphic delivery milestone

Date the exchanges rather than describe them

The exchange schedule is the operational core of the document. It states who deposits what in the common data environment, how often, with what status, and what other disciplines are allowed to do with it.

Without this schedule, model reviews turn into file-update sessions, and decision points get handled on already outdated versions.

Own the split of responsibilities

The BEP must explicitly state who produces, who checks and who decides. Clash detection produces a list of issues: it replaces neither the technical synthesis nor the design arbitration, which belong to the engineering offices and the design team.

This clarity protects everyone, including the BIM manager, whose mission is to organise and control the information system, not to validate design choices.

Keep it alive

A BEP frozen at signature becomes wrong from the first phase. Plan for a revision index, a change log and a review at every phase change: it's the only way it remains the shared reference all the way to the digital as-built file.

Key takeaways

  • A BIM use case is formulated as a decision to be made, not as a software feature.
  • Every data requirement must be translatable into an automatable validation rule.
  • An exchange schedule is worth more than a chapter of good intentions.
  • The split of responsibilities must be written down in black and white.

Go further

A project, a question?

Our interventions are built on your production context.

Contact us