Everything about BIM seems entirely straightforward for those “in the know” yet utterly confusing for those trying to understand. For those making the first steps into BIM, you may be encouraged to hear that even those experts you meet who are happily BIMming away also run into problems. We’re not talking technical issues here, although they exist, we’re talking far more fundamental problems: misunderstanding the content of another’s model, lack of expected data, even seemingly simple things like positioning and orientation, or what to put in the model. It’s these basic collaboration issues which, on the whole, will make a success or failure of a BIM project, and they are far more common than many would have you believe.
With any BIM project, it is critical to establish the way BIM will be executed… that is the purpose of the BIM Execution Plan. PAS1192-2:2013 defines the process for defining the BEP, and a series of other project documents, to enable BIM Level 2 working. But PAS1192-2:2013 isn’t a really exciting read, and it is clouded in obscure acronyms – BEP being one of the easier ones. In an ideal world the BEP is a response to the EIR (acronyms abound) and should also include the MIDP (made up from multiple TIDPs), the RM, PIP, SCCS… and aren’t you losing the plot already?
OK, so, enough of the technical jargon, what is the BEP and why is it important?
If you look in PAS1192-2:2013’s section 3 “Terms and definitions”, you won’t find a definition of BEP. There is one in Annex A however which defines a BIM Execution Plan as a “plan prepared by the suppliers to explain how the information modelling aspects of a project will be carried out.”
A BEP is one of the fundamental principles for Level 2 BIM (PAS1192-2:2013 page ix) and comes in two forms: pre- and post-contract award. Pre-contract it intended to be used to help evaluate a company’s proposed approach. Post-contract it becomes a collaborative document explaining who is responsible for what and when.
A BEP should contain the following (don’t worry, I’ll use non-technical terms):
- A list of roles and responsibilities, and capability statements.
- Major BIM milestones or deliveries related to the programme.
- Standards and procedures that will be employed, including:
- how information will be approved
- how collaborative information will be utilised
- how the models will be zoned and broken down for each discipline
- construction / modelling tolerances
- the location and orientation of all models
- file naming conventions
- layer naming conventions
- annotation standards
- A list of information & documents to be delivered in alignment with the project programme, identifying responsibilities and formats.
- A model delivery strategy, clarifying who is responsible for modelling each aspect of the building and to what level of detail (this should also define what attributes will be included at which stage).
- A strategy for types, accuracy and use of surveys.
- Use (and limitations) of existing data.
You can see, once you cut through the jargon, it contains many items you would expect to have to define anyway.
It becomes a very important aspect of the BIM delivery process as, if treated collaboratively, explains to the rest of the project team (called suppliers in PAS1192-2:2013) what they should expect from each other and when to expect it. In a collaborative environment it encourages positive interaction and understanding of the holistic process; in a combative environment (as unfortunately some construction projects can degrade into) it can be a record of what was actually agreed. It would usually become a contractual document. Positive or negative, the BEP is critical as it details what each company intends to deliver.
The BEP is not a sales or marketing tool. It should not be written to make you or the project team “look good”, but instead give a clear statement to the real capabilities and practicalities of delivering the project. Transparency is crucial to a successful BIM project.
Also, the BEP isn’t is a set of rigid standards to be issued by one party with which everyone must comply. In fact both BS1192:2007 and PAS1192 unambiguously state this “prescriptive” approach is not compliant with Level 2 BIM:
PAS1192-2:2013 page v
A project BEP should be put together from each company’s individual plans and should help describe how any differences in approach will be managed. It is not intended to be restrictive but describe the reality of delivering the project and, if they exist, the employers requirements for information. It should not prescribe software packages (as PAS1192-2:2013 is product neutral) but it should address any challenges of data exchange or formats and how they will be addressed.
Unfortunately, BIM Execution Plans are often poorly compiled and lack the information necessary for them to be properly useful. Imagine a simple scenario where the structural engineer needs to specify structural openings around a duct. Is the duct currently modelled as an approximate size or its designed dimensions? When will the mechanical engineer be providing that information? Or, what if a contractor expects the ability to replace all doors with the manufactured, as constructed versions. Simple enough? What if the windows do not have an attribute to define them as windows? Is the contractor expected to visually scan the model for all windows? Take it a step further: what if the contractor cannot identify a door because the architect has designed a door as an integral part of the curtain wall and classified it as such?
Neither party in any example above is right or wrong, but the BEP would define how the author intends to construct their information and what the other parties should expect of it. Where this becomes difficult is knowing what will be required. Personally, and professionally, I’d encourage people to consider additional detail in a BIM Execution Plan to clarify some of these potential ambiguities:
- BIM goals and uses
What you intend the model to be used for at each stage. This can help you work out what you’ll need to include in the model or not. Design coordination, for example, is a mostly geometric exercise, where non-graphical attributes would be less important. Procurement would need another level of data altogether and requires a much more rigid approach to classification.
- Level of Detail and Information matrix
More than a table of general responsibilities for each part of the model or activity, it is always beneficial to break down each deliverable into as much detail as possible. Look at how classification systems identify parts of a project and list out those you will be either responsible for designing or will require input into. Further than that, catalogue the attributes that will be included at which stage so the non-graphical data the BIM will contain is also obvious. Use descriptions and names that the authoring software uses as well. If IFC is to be utilised, map the components and attributes to the IFC entities and attributes that will be issued.
- Compatibility issues
Do not shy away from technical issues, but highlight them. This is an execution plan not a glossy brochure. Address them and state the workarounds, or if a solution is not possible, state that as well.
- Variances from contract / EIR
Finally, and probably most importantly, identify if the EIR or expected outputs of BIM will not be met. This might be because of technical limitations, current abilities (which may be met further into the project), or even impracticalities of the EIR (just because you are asked for it, it does not mean it is possible).
It’s usually a simple matter of sitting down as a team and listing what you would normally deliver for a “traditional” project and for what purpose. This BIM stuff isn’t as hard as the acronyms might have you believe, but being aware of what you are delivering is paramount.
Always prepare – and agree – a BIM Execution Plan for clear, consistent and unambiguous data.
Photo by rawpixel.com on Unsplash