The BEP subcontractors actually follow.

Why most BEPs fail

Open ten BIM Execution Plans from ten different projects in the Gulf and you will find roughly the same document. Thirty-odd pages of headings copy-pasted from a PAS 1192 template, a responsibility matrix that names roles but not people, a software list that nobody enforces, and a section on Level of Information Need that simply says "LOD 300 at design, LOD 400 at construction" without ever defining what either of those mean for a duct, a beam, or a curtain wall mullion.

The document gets signed. It goes into the project filing structure. It is referenced once in a kick-off meeting. And then the project happens around it, not because of it.

The reason is not that the people writing BEPs are lazy or that subcontractors are uncooperative. The reason is that most BEPs are written as compliance artefacts, documents whose purpose is to exist, not to be used. The test of a good BEP is not whether it passes a client review. The test is whether, six months in, when an MEP subcontractor is uploading a model into the CDE, they look at the BEP first and act differently because of it.

Almost none do.

What a BEP is for, actually

Strip away the standard and the BEP has one job: it is the contract between everyone who will produce information on the project. Not the legal contract, that lives elsewhere, but the operational contract. The thing that says, in unambiguous terms, what each party will model, to what depth, by when, into which folder, named in which way, and reviewed against which criteria.

Every clause in the BEP should answer one of those questions for one of those parties. If it doesn't, it's filler. If it does but the answer is vague, it's worse than filler, it's a future dispute waiting to happen.

This is why the best BEPs are short, specific, and dull. They name people, not roles. They give file paths, not principles. They give acceptance criteria, not aspirations. And they assume that the reader is a coordinator at 11pm trying to figure out whether what they just received is acceptable.

The five things every BEP must answer

Forget the table of contents in the template you downloaded. A BEP is doing its job if, and only if, it gives a clear answer to these five questions. Everything else is supporting material.

1. LOIN by discipline: to the element class.

   Level of Information Need is the single most abused term in the standard. "LOD 300" is not an answer. The answer looks like: "Architectural walls at concept = generic family, layered as core and finish, no fire rating; at design coordination = manufacturer-aligned family, fire rating populated, acoustic class populated; at construction = as-installed thickness, fire rating with certificate reference, attached to room boundary." Do that for every element class that matters on the project. If it takes forty rows, it takes forty rows.

2. CDE structure: folder by folder, who can write where.

   The Common Data Environment is not "we will use ACC." It is the exact folder hierarchy, the four-state workflow rules between WIP, Shared, Published, and Archive, and a permission matrix that says which company is allowed to upload into which folder. Vague CDE clauses are how files end up in the wrong place and how the audit trail dies.

3. Deliverable schedule: MIDP and TIDP, with dates.

   A Master Information Delivery Plan that lists package names and "design stage 3" is not a schedule. A real MIDP has dated rows: model file name, responsible party, named author, LOIN reference, exchange milestone, due date. The TIDPs sit underneath, one per task team, with the same level of detail. The dates in the MIDP must reconcile to the construction programme. If they do not, the BEP is fiction.

4. Acceptance criteria: what 'good' looks like.

   Every deliverable needs a definition of acceptance. For a federated model: zero hard clashes within MEP services, no clashes between MEP and structure exceeding 25mm, all rooms bounded, all spaces tagged, naming compliant with the project standard. Acceptance must be a checklist a reviewer can run, not a sentence saying "to a high standard." If it cannot be checked in 30 minutes by someone with a clash report and a model browser, it cannot be enforced.

5. Change control: how the BEP itself gets updated.

   Projects change. The BEP must change with them. Most BEPs have a single revision in the cover page and stay there for two years. A working BEP has a change log inside it, a named owner authorised to issue revisions, and a clause that says nothing in the matrix or schedule may be altered verbally. Without this, the document becomes wallpaper the moment the first scope variation hits.

A BEP is doing its job if a coordinator at 11pm can use it to decide whether what they just received is acceptable. Anything that fails that test is filler.
From the JES delivery floor

Common mistakes

Four patterns repeat across almost every BEP we are asked to review. None of them are technical mistakes. They are mistakes of attitude, the writer treating the document as paperwork rather than as an instrument.

Copy-paste from PAS 1192 or ISO 19650.

The standards are reference material, not deliverables. When entire pages of clause numbers and abstract definitions get lifted into the BEP, the document signals to its readers that nobody expects to use it. The standard belongs in the bibliography. The BEP belongs in the project.

Vague LOIN.

"LOD 300" was a useful shorthand in 2014. Today it is the single biggest source of disputes between consultants and contractors. A subcontractor who reads "LOD 400 at construction" cannot tell whether their generic equipment family is acceptable or not. The result is rework, finger-pointing, and a programme slip that nobody planned for. Define LOIN per element class, with both geometric and information requirements. It is more work upfront. It is the only thing that prevents the work later.

No acceptance gates.

If the BEP says "models will be reviewed for compliance" without saying what compliance means, what criteria are checked, who runs the check, and what happens if a model fails, the review is theatre. Acceptance gates are not optional, they are the only mechanism by which the BEP exerts any force.

No enforcement teeth.

A BEP without consequences is a request. The clauses that make BEPs binding are clauses that say: "models which fail acceptance criteria will be returned for rework at the originator's cost," or "exchange milestones missed by more than five working days will trigger a programme review meeting at director level," or "submissions not compliant with naming convention will not be logged into the CDE." The teeth do not need to be aggressive. They need to be present.

What 'enforcement' looks like

Most BEPs collapse not because the document is bad but because nobody runs the gates the document describes. Enforcement is a calendar, not a clause. It is a recurring review meeting, attended by named people, that opens the federated model, runs the acceptance checklist, records pass or fail, and triggers consequences for fails.

On a well-run project we run four kinds of gate review:

• Stage gates, at the end of each design stage, the federated model is checked against the LOIN matrix for that stage. Misses are logged with named ownership and a recovery date.
• Exchange gates, at every formal Information Exchange milestone the deliverables listed in the MIDP are checked off, in writing, by the Information Manager. Anything missing is escalated within 48 hours.
• Weekly clash reviews, open to all task teams, run from the same federated model every week, with a clash count that goes down not up across the project lifecycle.
• Audit gates, quarterly, by someone who did not produce the model, against the CDE permission and naming rules. This is the gate that catches the silent rot.

The BEP describes these gates. The project runs them. Without the running, the description is decoration.

A workable BEP outline

The outline below is not the only valid structure. It is the structure we use because it forces every section to do work. If a section in your template does not map to one of these seven, ask what it is for.

1. Project information and parties.

   One page. Project name, client, appointed parties, named individuals against each delivery team with email and phone. Not "BIM Manager, TBC." Real names.

2. Information requirements summary.

   A short restatement of the EIR, the client's information requirements, in the BEP's own words, so that everyone knows what they are responding to. Include OIR and AIR where they exist.

3. LOIN matrix.

   The heart of the BEP. Rows are element classes. Columns are project stages. Cells contain geometric and information requirements. Multi-page tolerated, one page never sufficient.

4. CDE structure and workflows.

   Folder tree, state-transition rules, permission matrix, naming convention with worked examples, file-format register, and the platform configuration. Include screenshots of the actual CDE setup, not generic diagrams.

5. MIDP and TIDPs.

   Embedded or referenced. Dated rows, named authors, every deliverable accounted for, reconciled against the construction programme.

6. Quality and acceptance.

   The acceptance checklist for each deliverable type. The gate review calendar. The consequences for failed reviews. The escalation path. The audit cadence.

7. Change control and revisions.

   Who can amend the BEP, how amendments are issued, the change log table, the version control rules. The clause that says verbal agreements do not amend this document.

Where to start

If you have an existing BEP and you suspect it is wallpaper, do not rewrite it from scratch. Open it next to the construction programme and run a simple test. For each deliverable in the MIDP, can you find a named person on the project who is responsible? For each LOIN clause, can you give an example of an element that does and does not comply? For each acceptance criterion, can you describe the check that gets run? If you cannot answer two of those questions for any line of the document, that line is filler and should come out.

What remains is the spine of a real BEP. Build the rest around that spine, discipline by discipline, gate by gate, with the calendar of reviews already in everyone's diary before the document is signed. The signature is the start of the work, not the end of it.

That is how you get a BEP that subcontractors actually follow. Not because it is enforced from above, but because it is the document they reach for when they need to know what to do next.