Writing a BEP that survives procurement scrutiny, not just an ISO 19650 audit.

ISO 19650 gives you a framework for a BEP. It does not give you a BEP that a client's procurement team will accept without pushback. Those are different documents, and conflating them is a mistake that costs time at exactly the wrong point in a project.

A procurement-ready BEP has to answer questions that an audit checklist does not ask. Who is the information manager, and what happens if they leave the project? Which consultant is responsible for federated model quality at each stage gate? If a clash is found in the stage submission that was not flagged in the coordination report, what is the contractual mechanism for resolving it? These are the questions a client's commercial team will ask, and a BEP that cannot answer them clearly creates risk for everyone involved.

The BEP also needs to be honest about what the project team can actually deliver. A document that commits to weekly federated clash cycles when the programme does not allow for the turnaround time, or that specifies a level of model detail that the discipline teams are not resourced to produce, is not a strong BEP — it is a liability that will be cited when things go wrong.

We write BEPs in two layers. The first is the compliance layer — the ISO 19650 required content, the employer information requirements response, the master information delivery plan. The second is the delivery layer — the specific workflows, responsibilities, and escalation paths that will actually govern how the project information is managed. Both layers have to be present for the BEP to be useful.

The test we apply before issuing a BEP is simple: could a project manager who has not been part of the BIM discussion read this document and understand exactly what they should expect at each stage gate, who to call if something is wrong, and how disputes about model quality will be resolved? If the answer is no, the document needs more work.