LOD – the biggest BIM con to date!

Overview:

Introduction:

There is no such thing as a perfect BIM (Building Information Modelling) protocol. Despite best efforts, Model Level of Development (LOD) from AIA G202^TM 2013 may have more than just a few quirks. It may be built on several false premises. This is even more emphasized when working outside of the US, and the accompanying AIA Digital Data protocols are not engaged (that is; AIA: E203 2013, G201 2013 and G202 2013 along with A101 2007 and B101 2007).

In my posts to date on Level of Development here: (below-detailed links have been added for clarification)

• 2013 - Developing LOD (Level of Development): A review on the changes from the AIA E202 2008 to AIA G202 2013. What improvements have occurred, and what still requires work.
• 2015 - A Review - BIMForum LOD Specification-2015 - A review on the 2015 BIMForum LOD Draft Specification (Released April 2015). What works and what doesn't. How to make the document work for you. This review has been updated to reflect the final November 2015 Release.
• 2015 - As-Built BIM: LOD 500 under the Microscope: Does the LOD 500 framework give clarity to the project team. This article proposes a new alternative to meet client and project teams needs.

I have tried to patch items within the AIA Level of Development framework which has not worked in the past; or refined aspects to try to get greater value on time invested. However, the more I study Level of Development, the more glitches I come across. Model Progression Specifications are a BIM project necessity, but they need to be an integral aspect of the project, becoming a pseudo project progression planning and analysis tool.

Pushing LOD (Level of Development) off the BIM Cliff

Note: Any reference to “LOD” is inferring to the AIA’s “Level of Development” framework as per AIA G202^TM 2013 and not Level of Detail.

Copyright: 

The works held within this article are the copyright of the BIMFix Blog, its author Brian Renehan and the other credited references. It may not be copied in part or in whole without the written permission of the author.

Flaws within Level of Development:

Below are some of the main flaws I’ve come across in the Level of Development framework. These comments below are based on what AIA G202^TM 2013 provides along with the accompanying guide. I am taking the documents at face value and I’m not trying to fill in the gaps.

No Progression Processes:

What is the process of a model element going from one Level of Development to the next progressive Level of Development, when does it occur and whom decides?

The AIA G202^TM Level of Development Model Element Table identifies the Major project milestones versus the Model Elements; who is the author, and what the proposed element Level of Development will be. So AIA G202^TM covers the planned progression. It, however, does not in any way cover the execution of the elements progression. That is:  

• Who decides when the model element reaches the next LOD level?
• What rigor is involved in determining an element is now at the next LOD?
• How do we manage a model element LOD being downgraded due to design changes, or unforeseen developments?
• What is the order of events, the relationship between model elements in order to achieve closeout?
• When prior to the project milestone does the element need to reach the required LOD status?

For a model element development specification, you would expect the AIA G202^TM to have development process flow diagrams to clarify the above items. It has none, and no accompanying text providing a process explanation. BS 1192-1:2007 is a form of digital data (model and documents) development specification. It contains 7 process flow diagrams identifying progression workflows and its guide contains 22.

Planned Verses Actual:

From above we see the current AIA G202^TM is limited to being a plan. A plan is just the first step. Understanding the actual progression provides real value to all involved. A model element development specification needs to be able to:

• Track planned progression versus actual, and
• Communicate development status on an element level.

In the Level of Development planning process, we currently break down the work into a UniFormat Level. However, design progression and resolution do not work neatly within classification systems. Some aspects of the design will be ahead, and some will be behind.

It is likely during a project progression, we will need to engage multiple levels of granularity in communicating and tracking status. These may include:

• Building or File,
• Zone or Floor,
• System or Assembly,
• Type,
• Component, & maybe even a
• Part level.

Understanding where we are in our progression is essential.

Authorized Use & Milestones:

It makes little sense the day an element reaches LOD n00, its Authorized Use for Analysis, Coordination, Cost Estimating and Scheduling changes dramatically from the previous day, especially as the change in status is planned to occur at the end of a milestone. How would this function in a typical progressive and iterative design environment?

Let’s look at an example design process for a Structural Beam using a BIM workflow during contract documentation:

• Analysis: The designer will use the beams analytical model properties to analyze the element within its Structural system. The outcome is a design intent member size, with a location at known dimensional tolerances.
• Coordination: A federation level coordination will then establish the beams exact location and potential penetrations.
• Scheduling: 4D analysis and simulations if engaged will determine the elements construct-ability, &
• Cost Estimating: will determine if the design solution is within budget and value management opportunities.

After each of the above steps, we may need to go back to the start of the process, due to an aspect which causes a result outside of the design intent constraints. The overall process may take several weeks, and may occur a few times in order to achieve resolution. It is a progressive process and is intended to occur prior to the stage close out; i.e. before the project milestone. However according to the AIA G202^TM LOD Model Element Table; the LOD Model Element deliverable occurs at the project milestone. That’s clearly too late and a breakdown in the process.

The same issue occurs during construction. At construction stage, there are dozens of potential model releases required to align with the construction program. The construction program is likely broken up into trades / levels and/or zones, with potential model releases required for each. So the major milestone approach won’t work during construction either.

Authorized Use and Element Status:

AIA G202^TM framework does not actually identify a current model element status. The intent is the model element is of LOD n00, with no sub-status granularity between. Yet, releasing model elements for “Coordination” (which is an ongoing project requirement); is very different to releasing a model element for “Cost Estimating”, which in turn is very different to releasing a model element for Fabrication. So the possible premise on how Authorized Use would operate on an actual model elements current status, will not satisfy required workflows.

No Document Control Integration:

On medium to large projects, it is preferred if a Document Management System (DMS) is utilized. These systems, often cloud-based regulate; - version control, document accessibility, document status, release and revision date, document author and recipient details.  Document and Digital Control in itself is a well-established methodology for identifying digital data progression and reliance (AIA G201^TM 2013 allows for a DMS). It is typically carried out on a file or container level, however, there is no reason why technology solutions will not enable a “Model Element Control” level or potential other granularity levels.

Some of these DMS’s are expanding their services to be collaboration platforms, and facilitate model hosting, review and comments including; RFI’s and Consultant advice notices, shop drawing reviews, commissioning and sign offs.

A DMS is also a valuable tool to enforce process approval and sign-off. Without a DMS being engaged, BS 1192-1:2007 would be near impossible to manage and enforce.

Yet AIA G202^TM protocols do not integrate with digital data control protocols and potential ICT (Information and Communication Technology) management systems. It is difficult to understand why, especially when DMS’s are becoming the norm? Integrating a Model Element Development Specification into a DMS could potentially remove some of the manual labor in adding the status data to the model elements.

No Project Stages Relationship:

Established project stages (i.e.: Schematic Design, Design Development, Contract Documentation, Tendering, Construction and Commissioning, Handover and Operations) are a keystone to all project deliveries. Understanding in what project stage an item was generated, dramatically changes how we rely on it. We are familiar how pricing off schematic design documentation will be very different, to pricing off a finalized contract documentation tender set. Why would the design and construction industry engage a well-established stage progression and sign-off process for the project, but have a completely separate approach just for the BIModel development?

The system has failed if we are saying a model elements development is only at LOD 200, and it is used as part of a Lump Sum Traditional Tender package. Either the Level of Development definitions is poorly worded, or work has not gone into the model element. My bet is the former. Maybe introducing a LOD 250 may resolve the issue?

Missing Lifecycle Integration:

BIM is intended to be about a building's lifecycle. However, the AIA G202^TM – Level of Development framework only covers Design, Construction and Handover. Brief / Program Generation, Feasibility / Business Case Studies and Facilities operations are ignored.

No QC Relationship:

Quality Control is an integral aspect of production and data reliance, yet there is no clear relationship between LODs and QC.

Some LOD Definitions are clearly Broken - 1:

LOD 100 is just confusing. It is anything you want, that does not meet the criteria of LOD 200. Items we had no intention of modeling, we can specify as LOD 100, as we can derive them from the neighboring modeled elements. Paint is not modeled and so it is attributed to walls/ceiling/doors etc. Thus we can call it LOD 100.
If paint data is specifically required; specifying how it is to be communicated will be of much greater benefit to all involved than specifying LOD 100 on a model element table.

Some LOD Definitions are clearly Broken - 2:

Let’s look at an example of LOD 300. Generally, a LOD 300 model element is developed sufficiently to derive traditional construction documents. Its definition is “a specific system, object, or assembly in terms of quantity, size, shape, location, and orientation.”  At what point can a design consultant, who is engaged to provide “design intent” information, say; their elements have reached this criteria? Following design intent data output: due to Tendering Value Management, Client Substitutions, Contractor and Sub-Contractor substitutions and construction level coordination the element size or location may change. The design consultant can only reliably say the element has met all the design intent criteria. Thus, despite most Level of Development plans identifying 80% of the model at lump sum tender stage reaching LOD 300. No designer will be able to put their hand on their heart and say, the identified elements are at LOD 300.

Some LOD Definitions are clearly Broken - 3:

Let’s look again at LOD 300. The BIMForum LOD Specification has had to clarify the meaning of the word “Specific” to really mean “designed element” from the LOD 300 definition. The definition of Specific actually is: specified, precise, particular, explicit or definite. That indicates the designer knows exactly what element is going to be installed, including its product model information. 

Designers who are typically requested to generate LOD 300 model elements are often not placed to specify proprietary products. The BIMForum LOD Specification authors clearly see the error in the definition. Maybe the AIA should fix it, or introduce a new LOD level.

Some LOD Definitions are clearly Broken – 4

LOD 500 is of limited valued to the project participants. See this (As-Built, LOD under the microscope) extensive post of the topic of As-Built data and its appropriate uses.

Development Level depends on the Author

During a project, a design team will model a system or assembly. During construction, the sub-contractors will take responsibility of the area, and change/remodel it to meet their construction requirements.

If we take a façade or cladding system as an example. The designers may bring this assembly to LOD 300. It is handed across to the sub-contractor and modified to meet their requirements. Due to value engineering, this may have included changes that have an effect on the design. The Sub-contractor now presents the model back to the designers. The Level of Development is still LOD 300, as it does not meet the LOD 350 requirements yet.  However, the Sub-contractors model is clearly more developed and closer to the final outcome. Thus, the Development Level is also clearly dependent on the Author.

Clients LOD Misuse:

It is a rarity to have a project BIM brief generated by a building owner to correctly specify a model progression specification using the AIA G202^TM 2013 framework.  The G202^TM form itself would never be used outside the US anyway, however if a client is to specify Level of Development they need to provide the appropriate context. All too often we still continue to see clients request design consultants to produce LOD 300 models, despite the AIA G202^TM accompanying Guide clearly stating there is no such thing as a LOD n00 model. These client’s worthless deliverable statements are a good example of how the industry clearly have not grasped model element Level of Development. 

We all know the design and construction industry is broken. It looks like the Level of Development framework is also broken?

LOD Legal Standing:

To my current knowledge, the AIA G202^TM’s Level of Development (LOD) framework has never been tested before a court of law. It would be a very brave legal team which would engage it, as from this article the premise could be dismissed very quickly. Let’s assume they did. It is my opinion (and I’m not a legal expert) the important aspect to a legal decision is:

• Has the supplier carried out their services in a professional and reasonable manner?
• Has the supplier provided a service which meets the customers’ identified primary outcomes?
• Are those outcomes reasonable?

If a firm is to be successfully litigated for a breach of contract, professional duty or damages; it won’t be because they failed to deliver all the model elements to LOD n00 which they had signed up to.

AIA G202^TM 2013 is also intended to be used in conjunction with AIA E203^TM 2013 which sets out the BIM and digital data proformas for the project. If these are not included, a BIM and Digital Data-centric project contract will need to be engaged to adequately cover these areas. I have not seen or heard of such a contract to date in the Australasia region.

Value to the Project Participants:

If you have ever spent hours filling out a model element table (all 2500 cells just for SD, DD & CD – from the BIMForum LOD 2015 Specification template), you start to ponder are you really getting value for all your work. As the model element table will be part of the BIM Execution Plan, it is likely it will spend most of the project time on a shelf.  At the end of each milestone, is there going to be any checks and balances to see if the planned LODs have been delivered? Is it not too late at the end of the milestone? If the model element progression specification was directly linked to the project program and plan of works, would that not be of much greater value to everyone!

Not an Integral Aspect of Project Delivery:

For a model element progression specification to be truly valuable, it requires being engaged as the default virtual project progression measurement tool. We thus need to be able to track and report on model elements at all levels. These may include:

• Revision status,
• Layout planning status,
• Analysis status,
• Coordination status,
• Costing status,
• Specification and Scheduling status,
• Graphical status for display in PDF outputs,
• Fabrication or Product selection status,
• Installation status,
• Commissioning status,
• Handover status.

The AIA G202^TM Level of Development will never be able to be engaged to meet all these approaches. It currently can’t even integrate with PDF drawings, schedules and specifications which may have been generated directly from the model itself.

Level of Development is trying to do too much:

Level of Development is endeavoring to make an often haphazard design and construction development process simple. It ends up over simplifying it. It tries to combine, Level of detail, Level of information, model element progression, Authorized use, and release protocols into one.

No Level of Development in any other Industry:

Level of Development in its premise as a framework around certainty and reliability is unique to the Construction industry. No other industry has anything like it. All other industries engage some form of level of detail along with design/manufacturing stages and element status’ of some kind. If the aerospace and manufacturing industry, which are years ahead of the construction industry have not seen the need for the premise behind Level of Development, why have we?

The UK BIM framework dismissed Level of Development:

In 2011, the UK Government decided it would create a 5-year plan to enable BIM processes to generate efficiencies, productivity gains, cost savings, reduced building carbon footprint and set the UK as industry leaders in BIM to enable the export of expertise. Industry experts along with funding was assembled to develop the required framework across the entire project to enable a BIM workflow. The parties involved obviously did not see the benefit in the premise behind the AIA’s Level of Development, the BIM Level 2 framework including, BS 1192:2007+A1:2015 & PAS 1192:2-2013, does not mentions Level of Development approach in any way.

Level Of Development Conclusion:

The AIA’s Level of Development when first brought out in 2008 was a bold and ambitious premise. It set out to revolutionize how we think about digital model progression in the construction industry. Unfortunately, the schema authors failed to integrate the progression into how projects are actually run, over simplified the progression approach and failed to add real value to all involved.

For anyone in the construction sector who are working outside the US and are not engaging the relevant AIA accompanying proformas (or similar equivalent), I suggest you start to investigate alternative framework to Model Element Progression approaches.

It’s time to push Level of Development off the cliff and look for a model progression specification which might actually work.