Tag Archives: BEP

Dissecting the BIM execution plan

September 7, 2012 By in Process Tags: , , Leave a comment

Following up on some posts I’ve made referring to the importance of the BIM execution plan (BEP), I wanted to go a bit more high level and talk a bit about what exactly it is that this document is supposed to do.

There are 5 major questions a BEP must answer:

  1. What is the objective for BIM on this project?
  2. What process will we be implementing to achieve said objectives?
  3. What standard of performance must the model meet in order to meet said objectives?
  4. What is included in the model, and who is responsible for including it? (This is your MET)
  5. How are others allowed to use the model?

There are, of course, other elements that people can add to this, like legal disclaimers, but at the core, this is what we should see. Naturally, a process change can create friction and unease. The BEP should go a long way to clear up any open questions across the team. Done correctly – allowing people to comment and participate – the process of developing a BEP should result in a clear definition of the rules one must respect in order to play the game. Without it, everyone plays by their own rules and the aggregate is no better than the sum of its parts.

Another couple of points to take into consideration are model ownership and whether the model has been defined as a contract deliverable or not. These will also have a large impact on how the BEP is structured. Usually, ‘self driven’ BEPs are much less strict and allow room for interpretation. Whereas ‘imposed’ BEPs can be hyper specific and dictate many areas of both the processes and technologies. We see this with the large owners usually…

All in all then, I believe that we should look at models like in a similar manner than we do the buildings. Many resources and processes are dedicated to their development and the end product should be representative of those who made it in both quality and reliability. When working with other parties toward a common goal, setting forth clear expectations is only good project management.

Beyond this, most BEPs will have a pretty tactical breakout of process and deliverable requirements. Unfortunately, most people see this as a sort of checklist that needs to be filled out. This isn’t the case. Defining the objectives for a BIM process on a project can and does have a huge influence on project delivery and should not be taken lightly. This touches everything, from people to decision-making, to contract documents. Losing control over deliverables is never a good place to be…

Asking for LOD alone is not enough

August 5, 2012 By in Process Tags: , , , , , Leave a comment

LOD, or Level of Development, is the system for classifying the amount of geometric detail within a model as set forth by the AIA’s E202 documents. James Vandezande has a great post on it from (believe it or not) 2008. The post does a great job at describing the different levels included, 100 to 500, and gives good reference to their intended meaning. Having used this systems on several projects now, I wanted to offer some feedback.

A few years back, when beginning to work on the Louisiana Museum and Sports Hall of Fame, I was inundated with emails and calls from just about every trade trying to figure out what constituted an acceptable deliverable. As the BIM Manager for the project, we were in charge of defining the requirements for a model deliverable that would be efficient, but also meeting the spec requirement for an ‘algorithmic coordination process’.

That project had another requirement that had a big impact on this conversation. The more than 1,000 unique cast stone panels had a surface integrity performance criteria that could only be achieved through CNC manufacturing. The fabricator, then, would be forced to model the panels and then use these models for mold making. This created a precedent. One of the more difficult elements in the design didn’t even have a choice but to create fabrication-level models. Did this requirement extend to the rest of the trades?

What if a trade wasn’t going to use the model for fabrication? What if they didn’t have the capacity to do so in their shops?

What became instantly obvious was that there was an ocean of space for interpretation in the LOD system. The specs called for an LOD400 model to be developed in the service of coordination. An LOD400 model is one that contains ‘shop drawing’ or ‘fabrication’ level of information. There was one big problem with this definition on this project, however. The lack of an explicit requirement on the model’s intended use left a gaping hole in the spec for a participant to interpret as they saw fit.  One company’s view of what makes a good shop drawing versus another can be very different.

The lesson then was to not just ask for a deliverable, but to also ask for that deliverable to meet a certain level of performance. A model used for fabrication will inevitably make for a model that is accurate for coordination purposes. The opposite, however, is not always the case.

In this project, the hook was to also ask that all information presented in shops (the legal document) also be present in the model. This way, the architect could use the model as a real reference in their shop drawing review process. The importance of this requirement was that it ties their legal deliverable with the BIM process. This made BIM central to their every day project management knowing the architect could reject a submittal by virtue of their model quality or completeness.

This move though would not work on many projects and is hard to enforce.  A better way to define model performance is to actually tie the deliverable to a good performance specification. That performance specification would include a reference to LOD. It would also include a responsibility matrix (the MET in the E202), and an intended use matrix. These three elements together make for a much better definition for model deliverables.

A good BIM execution plan (BEP) should include all these documents and a framework for their implementation.