Level of Development (LOD) is updated in E203

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…

All models are purpose-built, even when they’re not

The reality is that most models out in the wild today are built for one purpose: documentation. Yes, there are plenty of examples of models built for other reasons, but let’s just say the vast majority are out there trying to meet deadlines and if they have to throw in some drafting then so be it. In this case then, documentation was the intended use for the model, regardless of what your friendly neighborhood marketing department tells the rest of us.

Along the path of pointing out things that cause friction with design technology processes, mis-understanding the concept behind purpose built models is high up on the list. A purpose-built model is one that is built with an intended use (or uses) in mind. An example of an intended use may be something like ‘fabrication’, ‘documentation’, ‘engineering analysis’, ‘coordination’, and many others. The key consideration then, is that each of these uses requires slightly different geometry and / or model information.

Defining the intended use of the model gives clear direction to other users. Together with a defined level of granularity, or resolution, it is a powerful tool in understanding what information should and should not be in it. For this reason, many of the more thorough BIM specifications or BEP templates publicly available make reference to model uses.

The newly published New York Department of Design and Construction’s BIM Guidelines lists the following intended uses for their projects:

  1. Existing Conditions Modeling
  2. Site Analysis
  3. Programming
  4. Engineering Analysis
  5. Design Authoring
  6. Sustainability (LEED) Evaluation
  7. Design Review
  8. Code Validation
  9. Clash Detection
  10. Cost Estimation
  11. Construction System Design
  12. Phase Planning
  13. Digital Fabrication
  14. Record Modeling
  15. Asset Management

The VA, on the other hand, calls them ‘BIM Applications‘ and lists the following as a minimum:

  1. Space and Medical Equipment Validation
  2. Architecture – Spatial and Material Design Models
  3. Energy Analysis
  4. Design Visualization for Communication, Functional Analysis, and Constructability
  5. Building System Models – Sturctural, MEPF, and Interiors
  6. Masterplan Space Scheduling and Sequencing – 4D
  7. Communication of Construction Scheduling and Sequencing – 4D
  8. COBIE / Commissioning
  9. Clash Detection / Coordination
  10. Virtual Testing and Balancing

The GSA goes even further and has released individual guides for each of their sought after uses:

  1. Spatial Program Validation
  2. 3D Laser Scanning
  3. 4D Phasing
  4. Energy Performance and Operations
  5. Circulation and Security Validation
  6. Building Elements
  7. Facility Management

Some of these may seem a bit vague, but they all intend to direct a particular end use for a model. Each of these describes how the model will be used for each task, and what information should be included in the model in order to achieve said task. Notice how three large ‘owners’ that require BIM processes all are focusing on distinctly different things. They each care about different aspects of their facilities more. Be it security concerns for the GSA, equipment management for VA, or energy analysis for the DDC, each has implemented a process and frameworks to support their end goals. I’d like to hear how these are performing in real life…

In any case, this advice is not only for those consuming BIM. Those authoring and promising BIM to downstream users would do well to explain exactly what the model was built for. This will help frame expectations for the next user in line and many of the frustrations or mis-aligned expectations about what should or should not be in the model will be minimized.

Delivering BIM for FM isn’t without cost

Don Rudder, our CTO and I presented at RTC recently on our recent work implementing BIM for FM solutions. The presentation focused on what we’ve learned over the past year or so implementing custom workflows and tools within two hospital systems, the Porter Replacement Hospital in Porter, Indiana, and Children’s Hospital in Birmingham, Alabama. Both of these projects were done with the Contractor as a client, not the owner. In both cases, the contractor was acting as a proxy to the owner in helping them get the most out of what BIM they had developed to date, for downstream use during operations. I also want to point out that both projects are the brain child(ren?) of Aaron Wright, Hoar Construction’s BIM Director. It’s been his dedication to figure out the real application of a construction model during FM that brought us on board on both of those jobs.

Although very different, both projects faced similar issues: purpose built models not quite meeting necessary requirements for FM use; model craft required for coordination is different than that required for FM; information requirements for one is not the same as the other, etc. The list goes on… In any case, we knew there was value in there, we just needed to figure out how to squeeze it out, or better yet, how to repackage it to make it useful downstream.

Probably the more interesting development in all of this was that many of the more common issues weren’t issues at all, but instead general misconceptions about BIM and its utility over the lifecycle of a building project. One of these misconceptions was:

The only cost associated with BIM is its creation

This statement supposes that once you have a model, you’re done. This is a huge industry problem right now and is causing a lot of unnecessary friction. First, it falls into the usual trap of thinking BIM is a product and not a process. Off the bat, you’re thinking that the cost of BIM is finite and that once you’ve paid for a model, you can move on to the next item on your list. This is very much incorrect, and misses the point on a lot of the potential value to be derived. Yes, there is a cost associated with modeling, but the model is only a part of the process, not the end in itself.

The big misconception, then, is in thinking that there is no cost to maintain a model.  Again, if BIM is a process, then the process itself has a cost. If the product of a Construction BIM process is to be used during an FM BIM process, then one needs to budget for two things: first the translation of the construction BIM to something useful in FM, and second, the process of maintaining that BIM over the lifecycle of the facility.

BIM during FM should be dynamic and constantly learning about day to day facility operations.  If it is not, then you will quickly find its value degraded to no more than a ‘snapshot of the facility at the end of construction’. Over time, there will be enough difference between the physical facility and the virtual one that BIM will be set aside and lose its privileged position within day to day operations.  That moment marks the death of a model in most cases.

If you want to learn more about cost, effort and value of BIM, I recommend you read Mario Guttman‘s The Information Content of BIM