Lesson 10.2Lesson 10.2 · Doing BIM Well
Writing a BIM Execution Plan
The document that turns 'we'll do BIM' into a team that actually can — and how to write one people will use
The client says what information they need. The BEP is the team's promise of exactly how they'll deliver it.
In Module 5 we met the pair at the heart of ISO 19650: the client's EIR (Exchange Information Requirements — what information they need, and why) and the team's BEP (BIM Execution Plan — how they'll deliver it). This lesson is the practical craft of the second one: how to actually write a BEP that turns a good intention into a team that can execute.
Here is the honest truth about BEPs, learned the hard way across the industry: the worst BEP is the one written to win the job and then filed and forgotten. A BEP copied from a template, stuffed with boilerplate nobody on the team has read, changes nothing — the project runs on habit and the document gathers dust. A good BEP is the opposite: short enough to be read, specific enough to be followed, and alive enough to be updated. It is not a compliance artefact; it is the operating manual the team actually works from. Writing one that gets used is a skill, and it is the difference between BIM on paper and BIM in practice.
A BEP is judged by one question: does the team actually work from it? If it's in a drawer, it isn't a plan — it's an alibi.
What a BEP answers: who, what, to what standard, how, and when
Strip away the boilerplate and a BEP answers a handful of blunt questions, each traceable back to something the client asked for in the EIR. Who does what — the roles (lesson 10.1) and the responsibility for each part of the model. What information is produced — the model uses (Module 3), the deliverables, and critically the *level* each element must reach and when (Level of Development / information need, so nobody over-models or under-delivers). To what standard — the naming conventions, the classification, the file and data formats (IFC where open exchange is needed, Module 4), the CDE structure and its states (Module 5). How the team collaborates — the coordination process, the clash-detection cadence, the meeting rhythm, the issue-resolution loop. And when — the information delivery milestones, usually gathered into a delivery plan (often called a MIDP, a master information delivery plan) that says which information lands at which project stage.
The golden thread running through all of it is *traceability to a purpose*. Every requirement in a good BEP exists because someone will use that information for something — a coordination check, a quantity take-off, an operational handover. A BEP that specifies detail for its own sake ('model everything to LOD 400') has forgotten Module 3's hardest lesson: the right level is the one the purpose needs, no more. The best BEPs are ruthless about this — they demand exactly the information that will be used, and explicitly *don't* demand the information that won't.
Pre-appointment and post-appointment: a promise, then a plan
ISO 19650 splits the BEP into two moments, and the distinction is genuinely useful. Before appointment, the team submits a pre-appointment BEP — essentially a proposal: 'here is how we intend to meet your requirements, here is our capability, our proposed approach, our team.' It's part of how the client chooses who to appoint, and it's necessarily provisional. After appointment, the team develops the (confirmed) BEP — the real, detailed, agreed plan the project will run on, now that the actual team and their systems are known. The first is a promise made to win trust; the second is the plan made to keep it.
Why does this two-step matter? Because it forces the BEP to be *honest at each stage*. The pre-appointment version can't over-promise capability the team doesn't have (it's being assessed on it), and the post-appointment version can't stay vague (the project depends on it). It also mirrors how the information requirements sharpen: the EIR states the need; the pre-appointment BEP responds with an intent; the confirmed BEP commits to specifics, backed by the team's capability and capacity — which ISO 19650 asks the team to assess honestly rather than assume. The whole mechanism is designed to surface, early, the gap between what's promised and what can actually be delivered.
The EIR asks. The pre-appointment BEP promises. The confirmed BEP commits. If those three don't line up, you find out on site — the worst place to find out.
Writing one people use: short, specific, scaled and living
The craft is in making the BEP *usable*, and four principles carry most of it. Scale it to the project. A small project needs a short, sharp BEP — a few pages that name the roles, the standards, the deliverables and the milestones; forcing a 60-page template onto a house is the over-engineering Module 9 warned against, and it guarantees nobody reads it. A large infrastructure project needs the full apparatus. Match the document to the job. Make it specific and traceable. Vague clauses ('models will be coordinated regularly') are worthless; specific ones ('federated clash detection every fortnight, priority clashes resolved within five working days, tracked in the CDE via BCF') can actually be followed and checked. Assign real ownership. Every deliverable and every standard needs a named owner, or it's an orphan. And keep it living. A BEP is a controlled document that updates as the project evolves — teams change, scope shifts, the plan must keep up; a BEP frozen at kickoff is describing a project that no longer exists.
In India, this craft has a concrete anchor. CPWD's BIM guidelines (Module 9) require a BEP to be submitted within a defined window after award — a real, enforced deliverable on large public projects — and specify expectations like coordination-stage detail and a COBie handover. That's a useful model precisely because it's demanding but bounded: it tells the team what to commit to without pretending every project is a mega-project. Whether you're writing to CPWD's expectations or a private client's EIR, the test is the same: could a new person join the team, read this document, and know exactly what they're expected to produce, to what standard, by when, and who checks it? If yes, you've written a BEP. If it takes an hour to find that out, you've written a doorstop.
Turn a boilerplate BEP into one a team can use
A one-page BEP for a small health centre. Toggle each clause from boilerplate to something a team could actually follow.
The team will use BIM collaboratively.
Everything will be modelled to a high level of detail.
Standard naming and formats will be used.
Models will be coordinated regularly.
Information will be delivered as the project progresses.
The acid test
0 / 5 usableCould a new joiner follow the clauses still marked boilerplate? 'Models will be coordinated regularly' can't be acted on or audited. Sharpen every clause until it's specific — that's the craft.
Scaled to a small project, this whole BEP is one page. Forcing a 60-page template onto it guarantees nobody reads it — the over-engineering to avoid. The worst BEP is boilerplate written to win the job and filed away: worse than none, because it fakes the planning that never happened.
Three altitudes on the same idea
Read the band that fits you — or all three.
Learn what a BEP is and what it contains. The BIM Execution Plan is the team's answer to the client's information requirements (the EIR): it says who produces what, to what standard and level, in what format, through what collaboration process, and by when. Its core sections answer blunt questions — who (roles and responsibilities), what (deliverables and the level each element must reach), to what standard (naming, classification, formats, CDE structure), how (coordination and clash-detection process), and when (delivery milestones, often gathered in a MIDP). ISO 19650 splits it in two: a pre-appointment BEP (a proposal, to help the client choose) and a confirmed BEP (the detailed plan the project runs on). Every requirement should trace to a purpose — the right level of detail is the one the use needs, no more.
Write a BEP the team will actually use — short, specific, owned and living. Four rules do most of the work. Scale it to the project: a small job needs a few sharp pages, not a 60-page template nobody reads; a mega-project needs the full apparatus. Make it specific and checkable: 'models will be coordinated regularly' is worthless; 'federated clash detection every fortnight, priority clashes closed within five working days, tracked via BCF in the CDE' can be followed and audited. Give every deliverable and standard a named owner. And keep it a living controlled document — a BEP frozen at kickoff describes a project that no longer exists. The acid test: could a new joiner read it and know exactly what to produce, to what standard, by when, checked by whom? In India, CPWD's guidelines make the BEP a real, time-bound deliverable on large public projects — a good, bounded model to write to.
Treat the BEP as the project's information contract, and make it honest at each stage. ISO 19650's two-step is a governance tool, not paperwork: the pre-appointment BEP is assessed as part of selection (so it can't over-promise capability the team lacks), and the confirmed BEP commits to specifics backed by an honest assessment of the team's capability and capacity. Use that structure to surface, early, the gap between what's promised and what can be delivered — the gap that otherwise appears on site, the worst place. Insist the BEP trace every requirement to a purpose (kill 'model everything to LOD 400' — it's the level-of-effort failure of Module 3 written into policy), scale it to the project rather than deploying a universal template, assign real ownership to every clause, and mandate that it stays a live controlled document. And align it to the enforced local reality: on Indian public projects, CPWD's time-bound BEP requirement and handover expectations are the concrete target — demanding but bounded, which is exactly what makes them workable.
“A BEP is a formality — you fill in the template to satisfy the client and then get on with the actual work.”
Do it yourself
Draft the spine of a real BEP for a small project — the parts that matter, in one page.
- 1Pick a small real project (a two-storey house, an office fit-out). Write one line stating its BIM goals — the actual uses the information will serve (e.g. 'coordinated design, quantity take-off, and an as-built record for the owner'). Everything else traces back to these.
- 2List the roles (from lesson 10.1): who is the information manager, who coordinates, who models each discipline. Name real responsibilities even if one person holds several.
- 3Specify the standards in a few concrete lines: naming convention, the level each major element must reach and by when (traced to a use — no more than needed), file/exchange formats, and where files live (the CDE structure). Resist boilerplate; write only what this project needs.
- 4Write the collaboration and delivery lines: how often clash detection runs and how issues are tracked and closed; and the delivery milestones (what information lands at which stage). Now re-read the whole page and apply the acid test: could a new team member follow it? If any line is too vague to act on, sharpen it — that's the craft.
The one line to carry out
A BEP governs how the information is made. But once information about a real building exists and is shared, harder questions appear: who owns it, who is liable when the model is wrong, and how is it kept secure? Next: data, ethics and liability.
The author
Amogh N P
Architect, interior designer, and creative polymath. Studio Matrx began in his notebooks — his vision of design made honest, useful, and open to everyone. Its Academy is written and taught in his memory, and free, forever.
More about Amogh →