Tag Archives: LOD

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…

Level of Development (LOD) is updated in E203

August 21, 2012 By in Building Information, Process Tags: , , , 3 Comments

In the past few months, I’ve been involved in several conversations on projects that want to move forward with model based delivery, but are having a hard time understanding the legal implications. What does LOD mean to us? Does everything have to be in the model? What if is wrong? Mostly, people are consistently nervous about having an external definition to their instruments of service.

The reality is that the LOD system is not meant to be a prescription, but instead a framework. Unfortunately, it is also very vague, and has failed to guide people in its implementation. This has led to general confusion and even dilution of the effort as some have even come up with their own interpretations, many of them just plain wrong.

I recently came across James Vandezande’s most recent post on this and found his explanation to be most in line with the realities of those who are implementing this stuff on non-IPD projects. Probably the most useful aspect of the post is that he swiftly debunks the incorrect definition of LOD in the E202 context as being ‘Level of Detail’ (to be fair it does mean that if you’re thinking of the computer graphics term, which only adds to the confusion). What I like is that he provides a clear explanation as to why it is incorrect and even misleading. He states:

DETAIL = INPUT

DEVELOPMENT = RELIABILITY

This is probably the clearest distinction I’ve seen out there on the issue of LOD. What is most compelling about it, is the fact that it brings the conversation back into the realm of actual project delivery. We are not talking about abstract modeling concepts anymore. We are talking about the documents, or artifacts, that are used to actually design and build. This is very important because it places the focus back on the intent behind the model and elevates the status of the model from somewhere above a physical model (usually only a visual aid), to somewhere just below the actual drawings. It grounds a model back within the realm of process.

The Louisiana State Museum and Sports Hall of Fame LOD400 model

An update to the E202 with E203

Coincidentally, at the end of last week the AIA also published their updated Digital Practice Documents E203 – 2012, G2012 – 2012 and G202 – 2012 for public review. In it, there are a lot of improvements, but off the bat, one caught my eye. Section 1.4 of the E203 document lists the definitions and there are many more this time around that in the E202. There are some that were there before too, but have now been updated. One of these is LOD.

The new version, the E203 (2012) defines LOD as:

The Level of Development (LOD) describes the minimum dimensional, spatial, quantitaive, qualitative, and other data included in a Model Element to support the Authorized Uses associated with such LOD”.

Versus the old version, the E202 (2008) which defines LOD as:

The Level(s) of Development (LOD) describes the level of completeness to which a Model Element is developed.”

The new version refers to two other terms, Model Element and Authorized Uses, whereas the old version only refers to Model Element. Authorized Uses was actually not part of the E202 document at all. Authorized Uses is defined as:

The term “Authorized Uses” refers to the permitted uses of Digital Data authorized in the Digital Data and / or Building Information Modeling protocols established pursuant to the terms of this Exhibit”

The new version more clearly defines LOD as the minimum information needed to support the authorized uses. This new definition clearly speaks to James’ definition and I’m glad it’s made its way into the new documents. The prior definition was definitely misleading in that it seems to imply a geometric completeness over its intended use. It is a very clear directive to tell someone not only that they can use a model for a particular purpose, but that they may rely on it for that purpose.

We’ll see how people take to it…

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.