Delivery
The difference between a filed document and a working agreement is five sections.
Every project starts the same way. The BEP gets issued at kick-off, everyone nods, and the document goes wherever documents go. Six months in, run the only test that matters: when an MEP subcontractor uploads a model to the CDE, do they check the BEP first? Almost never. They ask the coordinator, or they do what they did on the last job.
That is not a discipline problem. It is a document problem. A BEP that nobody consults was written for the wrong reader, and most are.
The standard failure mode is the BEP written to pass a review instead of run a project: ISO 19650 clauses restated at length, organisation charts, a software list, role tables carried over from the last bid. ISO 19650-2 asks the delivery team to plan how information will be produced, what gets issued instead is a citation of the standard. A subcontractor who reads it learns that the project complies. They learn nothing about what to do on Thursday.
One BEP is the source of truth, not two. ISO 19650-2 separates a pre-appointment BEP from a confirmed one. The pre-appointment version is really the company's own plan, how JES works as an organisation, written to win the work. The confirmed BEP is then rewritten to match the client and the project, their CDE rather than the ACC we would default to, their requirements, their programme. Only the confirmed BEP is followed: it supersedes the pre-appointment version and becomes the single source of truth, so a project never runs on two.
A BEP earns its keep at the handoffs, the moments one party passes information to another and something can go wrong. Who hands what to whom, in what state, by when, checked how. Write the document around those moments and people consult it, because it answers questions they actually have.
Five sections do that work. The rest is appendix. One of them needs a word of its own. LOIN, the level of information need, combines the LOD, the level of detail or graphical representation, with the information held inside the family, so a requirement covers both what an element looks like and the data it carries, not geometry alone.
| Section | The question it answers | Without it |
|---|---|---|
| LOIN by discipline | What each element carries, at each stage | "LOD 300" means something different to every modeller on the job |
| CDE structure | Where work sits, who may move it | Models travel by email and file-share "to be quick" |
| MIDP with dates | Who produces what, by when | Deliverables surface at stage gates, already late |
| Acceptance criteria | What "done" means, checked how | Review meetings argue taste instead of running checks |
| Change control | Who owns a change, where it is recorded | Scope drifts verbally; the model and the instruction diverge |
Each of those five sections runs a page or two, written for the people who produce the information, modellers, coordinators, document controllers, not for the reviewer who files it. Acceptance criteria are checks someone can run in half an hour, pass or fail, not aspirations. And the MIDP is a live register with dated rows and named authors, reconciled to the construction programme and updated as the programme moves, not an appendix frozen at kick-off.
A document built this way also enforces itself. Every gate review on the calendar, stage exchanges, the weekly clash cycle, model audits, checks work against a named section of the plan. The BEP stops being a thing you comply with and becomes the thing you check against, which is the entire difference.
Run the week-twenty-six test on your current project. If the answer is "nobody opens it", the fix is not enforcement, it is a shorter document aimed at the right reader. Our BEP template is structured around exactly these five sections, and the ISO 19650-2 walkthrough covers how the plan sits inside the wider delivery cycle.
← All articles