IFC, What is it good for?

"IFC, good God, y'all
What is it good for?
Absolutely nothing, say it, say it, say it
Oh IFC, is an enemy to all mankind
The thought of IFC blows my mind
IFC has caused unrest within the AEC community
Frustration, then dissatisfaction, who wants to fail?"

with apologies to EDWIN STARR


Looking through blog posts and discussion groups there seems to be a lot of dissatisfaction with IFC. Some samples:

"It can (if done properly) be used for a static as-built record Information, but even when used for this purpose validation of the data is critical."

"Data Loss IFC has a horrible habit of losing information or dropping data when exporting from its native format."

" IFC is that it doesn't currently support all the clever time saving parametric stuff that we expect from BIM components these days. IFC is all about the geometry and data and upon export it normally dumbs it down to just that."

" The biggest barrier in my opinion is that no matter how good IFC becomes, it will never be as good or have the functionality as the native BIM package it was created in. "

"It annoys me when I see new BIM users (most of the time without software experience) shouting about how we must all adopt IFC & openBIM now-today, because on the outside it looks like a perfect solution, when in fact its actually a load of work arounds."


So what is going on? We keep getting lectured by BIM evanglists about how wonderful IFC is. These same evanglists are busily lobbying governments and large corporations to mandate IFC deliverables. There seems to be a lot of claims about what IFC can do, but little on what it can't do. I don't put myself forward as an expert on IFC and welcome comments that prove me wrong, but I thought I would share my investigation into IFC.

WHAT IS IFC

I won't go into a lot of detail of what IFC is, but paraphrased from wikipedia:
"IFC is an object-based file format with a data model developed by buildingSMART to facilitate interoperability in the architecture, engineering and construction (AEC) industry, and is a commonly used format for BIM. The IFC model specification is open source and is an official International Standard ISO 16739:2013.
For more information look at the buildingSMART web site, and as an example of their view of what Revit users need to know.

PROBLEMS WITH IFC

EXCHANGE FORMAT DOES NOT EQUAL OPEN FORMAT

One of the things many people don't seem to appreciate is that IFC (and by extension COBie) is an exchange format. It is not a common format, like open source formats (DOCX, JPEG, XVID, etc.), or common proprietary formats (DWG, PDF etc.)
IFC is designed to be a format that only exchanges data between other formats. When you import IFC into a software it gets converted into that software's format.
Software that can open IFC files directly are IFC viewers, they can't actually edit the IFC file.

It is a good idea, an agnostic data format.
But what it means is that there are two points of possible error creation - when the IFC is exported, and when it is imported.
With common formats there is only one - at import when using the software's format, or at export when using different software.
So although an exchange format like IFC may be theoretically more efficient across an industry, in practical terms for individuals it is not. To get a specific result it is easier (and quicker) to write one set of code in one software than to write two sets of code in two separate softwares.

FUNCTIONALITY

IFC doesn't seem to capture all the functionality of BIM authoring softwares. For example it contains size dimensions, but doesn't know which geometric entities these dimensions control. So it can't transfer working parametric objects.
Effectively an IFC import creates static objects, no longer editable.
This behaviour perpetuates problems that BIM is supposed to overcome. If size parameters are exchanged and are editable, but the geometry doesn't change with those edits, there is potential for situations where the scheduled size of equipment doesn't match its geometric size. Which makes spatial planning and clash detection unreliable.

BUILDINGS ONLY, NOT COMPONENTS

Although you can create an IFC file of a building that contains components, you can't create an IFC file of only one component. The file is effectively a building with one component in it.
I find this surprising. You would think an open format for distributing components would be high on the priority list.
There are a number of initiatives to create BIM component standards, like the UK NBS National BIM Library. But they have had to include Revit files due to the lack of functionality of IFC files.
That said, it should be entirely possible for a component IFC file schema to be created, and I believe buildingSMART is looking at this. See this presentation.
But currently IFC is not a suitable format for components.

ARCHIVAL QUALITY

IFC is pushed as an archival format. The argument being that the constant upgrades to proprietary software formats means any files retained now will be unreadable in the future. Whilst IFC, being a published standard, will always be readable.
But as explained above IFC is not a software format. It is an exchange format that requires other softwares to create and read it. Therefore it relies on proprietary softwares to maintain the ability to read older IFC formats. Which seems to me no different from relying on those proprietary softwares to maintain the ability to read their own formats. One could argue it is more likely they will do this for their own format than for an external format they derive no income from.
There is a mitigating factor though, the fact that IFC rarely gets updated means proprietary softwares don't have very many versions of IFC converters to maintain.
But the fact remains the problems of archival storage of digital data are NOT solved by using IFC.

AS-BUILT and FUTURE WORKS

IFC is pretty much useless for As-Built BIM that will be used as a resource for future changes to a building. As an exchange format IFC can't be directly edited. And most data that handles the original authoring software functionality has been lost in the exchange. So at best IFC can only be used as a static background in an authoring software with editing capability restricted to deleting parts.
Even if you import this static model there is the problem of loss of fidelity when an IFC file is imported into an authoring software. Without painstakingly checking every element it is not known whether everything from the IFC model has been replicated.
Then once the changes have been made in the authoring software, the export back to IFC is also problematic. If only part of the building has been changed how do you integrate that into the original IFC model?  If the whole building is exported back replacing the original IFC model how do you deal with the time lag that means differences in data content, or the problems that arise if the IFC model is linked to a third party database.

COMPLEXITY

I have looked through the IFC and COBie descriptions, and I'm sure if I tried really hard I could understand it. But I don't want to try, I've got more important things to learn that are actually relevant to my area of expertise. I'm an architect, not a computer programmer. I'm sure most people in the AEC industry feel the same way.
Just look at what IFC stands for - Industry Foundation Classes. What does that even mean? (when I talk about IFC to a project team they ALWAYS get confused and think IFC is "Issued for Construction").
Does this really matter? IFC is a software standard, not a human process standard. In theory us users should be shielded from the inner workings of IFC by the software we use. But the reality is we end up having to delve into IFC because the softwares don't provide what is required for us to do our work. We are also getting owners with specific IFC deliverables, that describe these deliverables in IFC terms.

DOES IFC ACTUALLY WORK IN THE REAL WORLD

This issue is one I can't answer because I am not a computer programmer. All I can go on is what I read in discussions and blogs by people who know a lot more than I do. And I have to say what I have read is concerning, some of the issues seeming to be rather fundamental.
It seems some that have tried to use IFC are, if not exactly giving up, accepting IFC limitations.
Jon Mirtschin at GeometryGym has been using IFC as an exchange method to transfer data generated in Rhino by Grasshopper to BIM authoring softwares. I saw him speak at an IFC 4 launch, and what he does is amazing, and he is a strong IFC supporter. But he admitted he was having problems with IFC and has started to write code to import directly into Revit to overcome them. It seems you can only go so far with IFC.
On another front Bentley have announced they are developing an "RFA interpreter" that can import rfa files (Revit's component file format) into their BIM product.

But even given IFC's problems, and despite my scepticism, IFC is actually being used around the world.

WHAT IS IFC USEFUL FOR?

Lets not throw out the baby with the bathwater. Underneath the practical limitations there is a fundamentally good idea. The fact is it is not, and never will be, the panacea it is claimed to be. But IFC must be useful for something.

ANALYSIS

Generally a BIM model used for analysis purposes doesn't require the whole model. Structural analysis only requires the structural components, thermal analysis only requires spaces, zones and envelope data. Some analysis software only requires parts of a building, or does the analysis one part at a time (e.g. floor by floor). Because IFC is an open format receivers of IFC files can break up them up without requiring the authoring software. Their analysis software may do it, or it can be done manually with third party software like simpleBIM at datacubist.com.
As IFC is usually simpler than the format of the authoring software so analysis softwares require less code to get the information they require, and it is easier for them to manipulate that data before importing it. This issue is becoming more important as cloud computing is taken up for analysis.
If all an analysis software does is the analysis then a static model like IFC is sufficient, but if you want to modify the model based on the results of the analysis IFC won't work for you.

So if you want to provide your model to some-one else for them to do an analysis IFC is a good idea, but if you want to do an analysis yourself that will result in changes to your model your authoring software is better.

FACILITIES MANAGEMENT

A Facilities Management system does not need the ability to easily modify a building's geometry. The geometry is mainly there as a navigation tool for the data the system holds. In fact you don't want people to accidentally move fixed elements  around (which can happen in authoring softwares).
You also don't want an unnecessarily complex file format that can do more than you need.
So using IFC for FM makes sense. It is a simple format that has its geometry locked down. It also makes sense, in theory, for FM software houses to utilise IFC as they can then import data from multiple sources. I say in theory because they then become victim to the quality of IFC those sources create.
Of course if you need to make changes to the building's geometry, like add a door or change a wall, you will need to do that with a different software and try and integrate that change back into your IFC model. I'm not aware of a way to do this, but I suggest you make sure you have a robust, tested, process before committing to a reliance on IFC for FM.  

COORDINATION

Current specialized clash detection software work by importing static models. They don't attempt, or have the capability to, alter imported geometry. Therefore IFC is a prime candidate for these types of software.
The ideal situation would be to have the ability to alter model geometry to over come clashes whilst doing the clash detection. But currently authoring softwares are not good enough at clash detection to make this practical. And then there is the issue of who makes the changes. Should the BIM Manager, who is not a structural engineer, have the ability to make changes to the structural model?

So at present, until authoring software improves and the responsibility problems are resolved, IFC is fine for clash detection and coordination.

WHAT IS IFC NOT USEFUL FOR

AS-BUILT FOR FUTURE WORK

IFC is not an authoring software format and in its current form is too limited to be really useful for making changes to an existing building.
However the pain associated with dealing with IFC could be alleviated by careful construction of the IFC model. For example by breaking it down into linked sub-models. If it is contemplated that IFC be used for As-built, as a minimum the process for updating building geometry should be established before hand-over to FM.

EXCHANGES BETWEEN AUTHORING SOFTWARES

IFC's inability the keep the data authoring softwares rely on to make them useful means IFC is a bad choice for model exchange. If all you require is a static background IFC may be usable, but only if you are confident all objects survive the double transfer - firstly from the originating software and secondly into the receiving software.
The other problem is even if you get the IFC into your authoring software the control you have over it (visibility, display, data content) may be limited.

COMPONENTS

IFC simply doesn't have the ability to contain the parametric properties we expect from BIM components. Maybe one day it will, but for now don't waste your time.

SHOULD IFC BE SUPPORTED?

When ever I bring up the shortcomings of IFC in public I get berated for not getting involved. It is open source, they say, anyone can contribute they say. But I'm an architect, I don't have the expertise to solve any of these problems. My contribution is limited to bringing up the short-comings of IFC. And I don't see how bringing up these issues in a closed forum could possibly be more effective than doing it publicly.

But should we practitioners support IFC? I believe we should. It is fundamentally a good idea.
Certainly volunteer to buildingSMART if you think you can contribute directly.
But if you want to contribute some of your time for free, my view is the most effective thing you can do is give IFC a try. Test it out, experiment with it.

And share you experiences. If things don't work bitch and complain, if they do heap praise on it.

IFC RESOURCES

IFC DISCUSSION
Linkedin:
http://www.linkedin.com/groups/Industry-Foundation-Classes-IFC-3690870

IFC VIEWERS
Solbri:
viewer: http://www.solibri.com.au/other-products/solibri-model-viewer
optimizer: http://www.solibri.com.au/other-products/solibri-ifc-optimizer
Tekla:
http://www.teklabimsight.com/downloads.jsp
List of IFC software:
http://www.ifcwiki.org/index.php/Free_Software

IFC / REVIT
Open source Revit to IFC Exporter:
http://sourceforge.net/projects/ifcexporter/files/

IFC to Revit importers (both are optimized for services and/or structure):
GeometryGym: http://geometrygym.wikidot.com/downloads
ArchiCAD: http://www.graphisoft.com/downloads/interoperability.html

Tekla (optimized for structure):
http://www.tekla.com/international/solutions/building-construction/Pages/export-revit-tekla-structures.aspx

IFC SOFTWARE
Software like simpleBIM (http://datacubist.com) can clean up IFC files.

EXAMPLES OF IFC USE:
Geometry Gym:
http://geometrygym.blogspot.com.au
http://geometrygym.wikidot.com

NBS [UK] Revit Plug-in:
http://www.thenbs.com/products/nbsplugins/index.asp

Bored with BIM? Need a present for that special woman in your life? The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, architecture and ... men. Book one of the series, "Awakening the lost woman", is available now on Amazon,  Google Books,  Kobo  and  iBooks.

Standards - Why don't we use them?

Its been a while since my last post, I took the opportunity of being in New Zealand for RTC Australasian to do some sight seeing. I have to also admit I was a bit "overBIMed". I found being immersed in a world solely of BIM, even for only a few days, taxing and a little demoralizing. But that's just me, my real love is architecture, not the technologies used to create it. It is certainly not a reflection on RTC events and how they are run. RTC are particularly great for those learning Revit and those wanting to improve their skills. I recommend it to those in the Americas and Europe where up coming RTC events are happening.

My talk on BIM execution plans, and my contribution to the Principle's Forum, didn't follow the "BIM is fantastic and problem free" line of most other contributors so I (deservedly) copped a bit of backlash.
One accusation was that I was being overly negative (some-one has to be), including not being supportive enough of open standards like IFC, COBie etc.

To be clear I think standards are a good idea, and more than likely necessary for BIM to become really useful. But a good idea is not enough. There is a bit of a circularity in standards - they are only useful if enough people use them, but to be used they must be capable of being useful, that is, practical.

The way BIM evangelists talk there is no good reason not to use standards. So why don't we? If they are so fantastic why do we need convincing?
I've tried to tease out some of the reasons that make us resistant to using standards.

WHY DO WE RESIST STANDARDS

STANDARDS REDUCE EFFICIENCY

We all try and be as efficient as possible. We work in a competitive field, there is no slack, no leisure time for processes that aren't immediately necessary.
So we try use the most efficient process for the task at hand. This is why processes are different on different projects. Each project has its own drivers and participants.
Using standards may be more efficient overall - over the entire project life - but not necessarily more efficient for each participant in doing what they need to do.

STANDARDS ARE NOT ALWAYS RELEVANT

At best standards strive to be "average best practice". Some would say lowest common denominator. Within any standard, for a particular project, there will be some parts of that standard that are not applicable, and there will be things that the standard doesn't cover.
For this reason, in the real world, it is never possible to "fully" comply with a standard.

STANDARDS GET OUT OF DATE

By their very nature standards are consensus documents. Even if many parties don't contribute, many parties have to approve and agree to its contents. This means they take a long time to appear, and are rarely updated as it takes so long. The latest version of IFC took 6 years to be published.

ANOTHER THING TO CHECK

If you comply with something some-one has to check that it is happening. To use a technical drawing standard as an example, not only does some-one have to check a drawing communicates what it needs to, it also has to be checked it complies with the standard. And they are not the same. The fact a text note is in a font not in compliance with the standard doesn't mean it is not communicating what it needs to.

STANDARDS OVERSHADOW THE REAL WORLD

The danger in unquestioningly imposing standards is that those standards are treated as more real than the real world. Complying with the standard becomes more important than ensuring that the job at hand is achieved. To use the example above, drawings are only checked to see they comply with the technical drawing standard, not that they adequately communicate.
I've been called into meetings with contractors because they couldn't get the information they require from drawings that slavishly followed a drafting standard (AS1100) but didn't communicate the information they needed.


Looking back on these reasons, it occurs to me that the problem is not standards in themselves, but the way we approach standards.
If we treat them with absolute reverence, or conversely if we treat them as just another unquestioned burden, these problems will occur. But if we treat them as a resource, something useful in certain situations, they become a practical proposition.

Like I said above, standards are a good idea. There only a few, but powerful, reasons to use standards.

WHY USE STANDARDS

COMMON UNDERSTANDING

Standardizing the way things are done, and being familiar with that standardization, improves communication and comprehension. Having a standard for graphically showing door swings means everyone immediately knows which way a door opens.

REDUCES ENDLESSLY INVENTING THE WHEEL

Having an agreed way of doing something means everyone can spend less time working it out from first principles.

REDUCES THE NEED FOR LEGENDS AND EXPLANATIONS

In principle you can use any method you want as long as you explain it. But explanations take extra effort. By following a standard you can just refer to that standard rather than include detailed legends and schedule notes.


These are generic reasons. But with computerization, and the wealth of data BIM produces, there are other reasons for using standards.

BIM and STANDARDS

This may come as a surprise to you, but computers are not people. Computers are not good at using context to classify information, they require more precision (an example of which I explore in my post Which direction is Depth?).
If one digital system is going to communicate with another the information exchanged must be in a knowable form. The obvious way to achieve this across many different softwares is to impose some form of standard. There are many standards within the software industry that us users are (thankfully) unaware of. So when I talk about standards I mean ones that effect how we work, not how the software works.

Which leads to some interesting points.

WE DON'T CONTROL OUR SOFTWARE

Us users can only control what we do, we can't control what our software does. So when we are asked to provide IFC files, for example, all we can do is provide what the software produces. If it is inadequate there is nothing we can do (beyond employ programmers to work around the problems). No software vendor will  take responsibility for what their software produces so it puts us in an impossible situation.

WHY ARE WE RESPONSIBLE?

And at what point are we, the users, responsible for ensuring adequate communication between different softwares? How much effort is reasonable to overcome what is in essence a problem outside our areas of expertise?
Is it reasonable to ask us to rename all our components (e.g. Revit families) just so the FM software can understand what it is being given?
Is it reasonable to ask us to use phasing (in Revit) in a way that helps the 4D software work? (we have just had this request on a project).

But when I get these requests I always wonder why. Why are we being burdened with extra work because of the inadequacies of software. Or is it the inadequacies of standards?

I'm not an expert on either, so I can't answer that. Perhaps it is a mixture of both. All I know is we are the bunnies caught in the spotlight.


But back to what we can control. Overall standards are a good idea, even ones to do with software. But use with caution. Treat them as guides, not commandments. Use them where they are useful, ignore them when they are not. And if following a standard creates more work, say so, don't fuel the myths peddled by the BIM evangelists.

In my next post I'll have closer look at the elephant in the room, IFC and it's sibling COBie.

BIM for free

l thought BIM meant others could make use of the BIM data each of us created for our own purposes. Now it seems to mean others telling us what BIM we have to do to suit their purposes. When did this happen?

 
When I first starting pushing BIM one of the arguments was that besides the productivity and QA benefits others could make use of the data we put in as part of our normal processes. A benefit at no cost I argued.
But now I have trouble convincing people to take up BIM because they fear clients will start asking for extra services, expecting it for free. 
This attitude is not surprising when looking through current BIM guides and example contracts. The owner is expected to make BIM demands & deliverables.

Why not have a system where BIM data that will be produced is made explicit by each participant and everyone, not just the owner, offered it 'as is' for their own purposes?
If this is done as part of the selection process those with the best BIM capabilities will float to the top. They may even get better fees.

A by-product of this approach would reduce the importance of single Project BIM Execution Plans and "BIM Managers". Each participant does their own BIM plan setting out what they do and don't do. They refer to each other's BIM plan to see what they will get and therefore what they have available to work with. Then each can negotiate with others to change what is being provided to come to mutually beneficial arrangements. 

Surely this is a better approach to encouraging BIM take up than dictatorial demands that creates resentment rather than enthusiasm. 

HOW?

But for this to happen authors (typically Architects and engineers) need to be clear about what BIM they will produce, and just as importantly what BIM they will not be producing.

And consumers of BIM (typically contractors and facility managers) need to be clear what they require to use BIM in their processes. They need an idea of the minimum they require, and the cost/benefits of "nice to have" extras.

I am constantly surprised at how rarely this happens. Design consultants marketing the benefits of BIM without specifying what they will actually provide, owners asking for BIM without even knowing what FM system the BIM data will be used for. And then there are the contractors who say we're not using BIM at all if it costs any extra, no matter what the overall project cost saving might be.

On the face of it the contractors appear to be the only honest ones. But they are throwing the baby out with the bathwater. You can get BIM for no cost.

If the design team use proper BIM software, the way it was designed to be used, useful BIM deliverables can be extracted.

There are some limitations. Information is limited to that required by the author to inform how their part of the building is to be built; design intent by the consultant team, fabrication by sub-contractors.

The other limitation is it may not be delivered in the BIM format required for down stream use.

Even with these limitation there are quantifiable benefits in using this BIM data. There may be extra costs collating this data into a usable form, and converting it into the required format. But like every other part of the construction process I would expect a cost / benefit analysis to inform what is worth doing and what is not worth doing. 

So why aren't we concentrating on how available BIM data can be used, rather than fantasizing about the missing BIM data and how it could be used?

Using BIM to Shirk Responsibility

In the BIM evangelist's ideal BIM workflow, where does responsibility lie, and how it is defined? And what does the term "collaboration" actually mean in a BIM context?
I've explored collaboration before (Real Collaboration - Working with Engineers), but it is bandied about so much it deserves more thought.

As BIM workflows are taken up this issue of responsibility is a sleeping dragon. IPD is put forward as a solution, but all that really does is take the problem out of the court room into a board room, where not all players are equal (see my post Integrated Project Delivery: Bad News for Architects?).

But am I being alarmist? Is it really going to be a problem? The test is what happens in the real world - let me tell you a story . . .

You want me to do what?

There is a project, a Design & Construct (D & C) project. The first contract is for the piles that hold the building up. The piling D & C contractor has to design and build the piles (even though the project has a consultant structural engineer). Let's be clear - they are responsible for the size, location and number of piles.

The architects notionally draw the piles in their model to recognise their existence. The structural engineer puts them in their drawings with spacings and locations, based on their designed structure; where they think they should go.

The architects were asked by the head contractor to set out and dimension the piles. The project architect didn't want to do it, the structural engineer said the architect shouldn't do it, but the director in charge wanted to keep the head contractor happy.

As the contractor provided no information it was done based on the structural engineer's drawings. They were using CAD, the architects were using Revit. The architects inspected the structural engineers CAD drawing and there were some dodgy dimensions - dimension text that didn't match the measured distances. So the CAD file was ignored and the piles set out based on notes and dimensions in the CAD drawings.

The architects issued their drawing, as a CAD file, to the head contractor. A little while later they got a call from the site foreman. Why didn't their CAD file match the structural engineer's CAD file? There was one extra pile in one location, one less in another. On investigation it was found the structural engineer's note - max. 1800mm centres - was followed, but their CAD file had the piles spaced greater than that, 1823mm. In another spot they showed 3 piles with dimensions that had been faked. When the piles were laid out using these dimensions they were very close together, much closer than 1800mm, so one pile was left out. The architect who did the modelling followed the structural engineer's drawing to the letter.

When the project architect went through it with the structural engineer, they said 1823mm is fine, and that yes, they did intend to have 3 piles very close together.

Now THEY can make that call, structure is their area of expertise and their responsibility. But all the architect can do is follow their drawing, or risk a negligence suit for wilfully overriding the advice of the appropriate expert.

ISSUE NO. 1

If you get someone to draw up the work of some one else they don't understand what they are drawing.

In BIM terms, if you expect some one other than those with the expertise to model or enter data you are likely to get incorrect or at best sub-optimal results.

But wait, there's more . . .

The head contractor has a surveyor on site. The architect was issued a survey drawing that supposedly showed the as-built location of the piles. It was a CAD file. But the piles shown matched their earlier CAD file, the incorrect one.
Did the contractor build off the incorrect CAD file or is the surveyor passing off the architect's CAD file for something they have measured on site?
As the site foreman made the architects change their drawing I suspect the latter (I haven't heard if they ever found out).

ISSUE NO. 2

Using the work of others and passing it off as your own.

Whilst I don't get too upset about others using my efforts to line their pockets, I do have a concern about accuracy and responsibility. When using the work of others it is far too easy to not bother to check that it is correct for your purposes. There is a tendency to blame others; the contractor didn't follow the drawings, the architect drew it wrong.


And if the incorrect CAD file was used by piling contractor to build off why were they using the architect's CAD file to build from? As a D & C contractor shouldn't they have produced their own set-out drawing? It would have been easy to do, they had CAD files both from the architect and the structural engineer.

ISSUE NO. 3

Using the work of others to shirk responsibility.

By not producing drawings under their title block there is no evidence the piling contractor made any mistakes in the design of their set-out. The only evidence is the architect's and the structural engineer's drawings. But these two parties were not responsible for the piling design. The contractor has effectively shifted their responsibility to others.


So what you say, sounds like a normal day at the office. It all about human error, nothing to do with BIM.
But it is always about human error, that's why we have contracts, a legal system and technologies like BIM, to ameliorate our human foibles. And one of our human foibles is to shift future blame (i.e. responsibility) on to others where we can.

Contractors are "killing it"

But is this story typical? What led me to write this post is a comment I read from another blog - Epic BIM. It was about another topic, the comment was put forward as an example of contractors keeping solvent by leveraging BIM. It was the way they did it that caught my attention:

" I had to work on a way to shrink my contingency. I quickly learned that I could take the CAD drawings and load them up into a data collector, which allowed us to lay out in the field 100 times faster than I had been doing, plus much more accurate. This lead into better scheduling of my equipment on site. Those two things alone made such an impact on the margins that it became a 'no turning back' point for the entire company. All this, allowed me to roll this up in my next bids, where I was killing it. "

So they are "killing it" because they are taking the work of others - their CAD files - and using them directly do their work.

Engineers must feel the pain. They are now being required to do what they previously didn't - model accurately (see my post Should Engineers model accurately?), but it is others who are reaping the profits.
Architects are used to it. Getting their own drawings back as shop drawings with the only difference being a new title block is not uncommon.

I'm not being critical of contractors earning more money by being innovative, my concern is who is perceived to be responsible. If a piece of ceiling falls and kills someone because the CAD file was missing some hanging points who is at fault? The CAD file was "incorrect", but the author of that file was not responsible for adequately supporting the ceiling, the contractor was.
What is going to happen in court? I don't know about the rest of the world, but here in Australia the legal fraternity, like most lay people, is quite ignorant of the complexity of building practice and the division of expertise and responsibility.

As I see it, the only protection we can utilize is the "use at own risk" clauses we use when issuing CAD and BIM files. Although I don't know if they will actually help when someone's life or large amounts of money are involved.

The alternative is to take responsibility for everything and associated risk and try and get paid for it.

ISSUE NO. 4

It is unreasonable to expect one party to take responsibility for, and therefore be expert in, everything.

If the producers of BIM models take on the responsibility of the completeness, accuracy and appropriateness of their model for any future purpose they will need to be experts in absolutely everything.



It is why we have professionals, who have Professional Indemnity Insurance. Expertise is split between architect, engineers, surveyors etc., and if they make a blunder they can be sued for the damage they caused. How does this work in a BIM workflow, where everyone works "collaboratively"?

The problem is "collaboration" is poorly defined, which is an invitation for everyone to have their own definition of what it means.  I've sat in a BIM Execution Planning meeting where the Quantity Surveyor thought "collaboration" meant we, the architects, would put their costing codes into our model so they could use our model for their estimates.

A definition of "collaboration" I like is "sharing". We will freely share our data with the rest of the project team. But only on an "use at own risk" basis. Our work is suitable for defining the architectural (or engineering) design intent, nothing else. Everyone who uses our data must satisfy themselves it is suitable for their purposes, end of story.

Unless data is shared on this basis it is too risky to do so. It shuts down "collaboration". I don't see how forcing collaboration through contracts without this protection will work.
Yet I see commentators making light of this concern by invoking the "BIM must be mandated to succeed" and that it will all be fixed "once we get BIM contracts" mantras.
And in any case why are we not questioning the assumption that collaboration can only be achieved via compulsion, and not through enticement? Seems a very "anti-collaboration" approach.

Another misguided approach is to insist that a BIM Execution Plan will magically solve it without detailing how. It doesn't matter if the BIM Execution Plan says the model must "be suitable for", say FM or 4D or 5D. The reality is that architects and engineers don't have expertise in these areas, so how can they possibly deliver what is required, let alone expected?

The bottom line is no one should accept enforced collaboration through BIM contracts without safeguards to their risk and responsibilities.
Until someone comes up with a viable alternative I continue to recommend everything be issued as "use at own risk", no matter what the contract says.

Another reminder for this year's RTC Australasia conference in Auckland 16th to 18th May, where I'm presenting "BIM Execution Plans: Avoiding the Noose".

Creating a BIM Project Brief (BPB)

In my last post I suggested ways owners might establish what they require out of BIM. This post I look at a way owners could quantify what they want, and how an owner authored Project BIM Brief (BPB) might be constructed.

NOT EVERYONE IS A BIM IDEALIST

At the end of the day BIM is no more than a method to improve profitability. Either through lower overall cost or better quality for the same cost. There is no point insisting on BIM or BIM deliverables just because it is a "good idea".
So the purpose of writing a BPB is not to describe an ideal BIM process based on "world's best practice". The purpose is to write something that describes what you actually require.

BIM SCOPE

Whilst it is easy to say you must define what you require out of BIM, it can be bewildering in practice. I propose (yet another) BIM concept to simplify and quantify this process - BIM Scope.
It loosely follows the BIM Maturity model by Richards & Bew, but with the value loaded word "Maturity" replaced by "Scope".

The purpose of BIM Scope is to define the level of BIM required, and then use that to tailor the contents of a BPB. Following the BIM Maturity concept there are four levels of BIM Scope:

0 - no BIM required, but BIM encouraged.
1 - minimum, utilizing design BIM.
2 - partial, utilizing construction BIM
3 - full BIM, for FM

Each level is cumulative -  that is it contains the scope of the preceding levels.

Each level can produce the products of previous levels, although these products may not be required as a deliverable.
Deliverables can be dropped or moved into another level. For example Level 2.5 might be Level 2 plus FM COBie & IFC data, but not As-Surveyed BIM model or iBIM. The idea is to provide a flavour of the scope of BIM required, not an exact measure.

To clarify the different ways what are traditionally called "As-Built" documents of a project can be delivered I have used:

As-Built
Final version of Design Intent documents, including all instructions issued by the design team.

As-Constructed 
As-Built revised to include items not normally present in design intent documents and instructions issued by contractor. May include final versions of shop drawings.

As-Surveyed
A BIM model of the constructed building based on surveys of actual built and  installed elements.

BPB CONTENTS

The BIM Scope level selected will inform what each section of a BPB contains. For a BIM Scope Level 0 some sections may be one sentence, but generally a BPB should include all the following sections.

INTRODUCTION

Describe where the BPB fits into the overall BIM Management Plan (BMP). Refer to my previous post Single project BIM Execution Plan: a good idea? for more information on the structure of a BMP.

REVISIONS

A place to record revisions to the BPB, but also where there is a description of the process to revise, approve, and distribution it.

DEFINITIONS

A very important section. Provide definitions as used in this BPB, not generic industry definitions. Read my post It's OK to not do BIM on an example of the importance of defining what is meant.
For example if the intention is BIM Scope level 1 then BIM in this context may mean BIM for construction only, not the usual definition found in Wikipedia. Alternatively define another term for what you mean. In this example you might use VDC (Virtual Design & Construct) instead of BIM.

OWNER OBJECTIVES

List the outcomes you are expecting from BIM deliverables. Besides being a valuable exercise for the owner to go through, it acts as a control point for all deliverables. Will a deliverable contribute to one of the objectives?

OWNER BIM USES

List the BIM uses deliverables will be used for. Only include specific uses required by the owner to achieve one of their objectives.  For example 4D (programming) is not an owner BIM use, it is a contractor BIM use. 5D (costing) is not an owner's BIM use, it is their cost consultant's BIM use.
If it is considered that other's BIM uses are desirable on the project describe the deliverable you would get from their use. For 4D you might have "3D visualisation of staging to stakeholders". For 5D "costing based on frequent and accurate quantities".

BIM DELIVERABLES

List specific BIM deliverables by the different parties, which may include:

• Design Team
• Contractor
• FM provider

Deliverables from all parties may not be necessary, or there may be others not listed above. It will depend on the BIM Scope and how the project is structured.
Only list BIM deliverables. Other deliverables should be covered elsewhere in other documents. For example delivery of construction drawings is not a BIM deliverable, but deriving construction documents from a BIM model is.

MINIMUM MODELLING REQUIREMENTS

Define expectations of how BIM models will put together. Depending on the BIM Scope, this could be:
General Description
  e.g. model assemblies larger than 100mm (4")
Specific Description
  e.g. All architectural elements built-in, all main structural elements (but not connections),
   all fixed ductwork, all cable trays, all pipework to fall and/or with diameter > 100mm (4"). 

LOD Table

  a simple AIA E203 type table, or full blown USACE M3 type table.
  (refer to my post What is this thing called LOD for a description of LOD tables).

BIM EXECUTION PLAN (BXP) REQUIREMENTS

As described in my post Single project BIM Execution Plan: a good idea? each participant should be required to produce their own BIM plan within the framework of the overall BIM Management Plan.

This section is where the minimum requirements for those plans are set out.

It is important to describe requirements as "minimum", and keep to what is critical. It shouldn't be a place where others are taught how to do a BIM plan. Whilst other BIM guides and standards may be referenced (AEC[UK], USACE, NatSPEC etc), be careful of requiring "compliance" with them. Better to use words like "similar to" or "in general compliance". None are 100% suited to all projects, or structured to suit everyone's needs.
Again the BIM Scope will inform what is required. BIM Scope Level 0 only requires Participant BIM Plans, Level requires a Design Intent Collaboration Plan as well, Level 2 also Construction BIM Plan (refer BIM Scope diagram above).

COMPLIANCE EVIDENCE

Set out processes that check requirements of the BPB are being met.

This may include deliverables like:

• Statements about how the various BIM Plans meet the objectives of the BPB.
• Approval processes for the various BIM Plans and their revisions.
• Audits of BIM models to show minimum modelling requirements are being met.

SPECIFIC INFORMATION

Specific information relevant to the project should be provided as appendices.
For example if the owner is doing their own FM their specific FM requirements, like what data is to be captured and provided, should be supplied as an appendix. If COBie is a deliverable define what fields are required, if IFC what version and what parameters etc.
As appendices they can be updated separately to the overall BPB.

TAKE OWNERSHIP OF YOUR PBP

I apologize for this description being some what generic, but when I attempted a more detailed description it quickly became complicated and unwieldy (like all the published BIM guides).

At the end of the day you have to make your own PBP that is meaningful to yourself and those who will need to rely on it. My experience is that trying to adapt a BIM plan that attempts to cover every eventuality and follow some theoretical "best practice" is more work than just writing down what you know you want.

If you just write something under each of the headings above, no matter how short, that addresses the topic of that heading, you will create a useful BIM Project Brief. Certainly something more useful to a design team, contractor and FM provider than a regurgitated BIM plan based on one of the published guides.


This, and more of my views will be expanded at this year's RTC Australasia conference in Auckland 16th to 18th May, where I'm presenting a talk called "BIM Execution Plans: Avoiding the Noose".
 

What BIM should Owners ask for?

There is an assumption in current BIM guides that owners will, and should, direct BIM on a project. But owners are not experts at construction, and not necessarily experts at FM. After all, that is why they employ others to produce their building. But owners have a stake in BIM use. Out of all the participants they are the ones who have the most to gain. So if owners shouldn't get involved in matters they are paying others to do for them, how can they influence the BIM process?

DEFINING WHAT THEY WANT

It is critical that the owner is the one who defines what they want. There is little point getting the lead consultant to do it as a "return brief", or engaging a BIM evangelist (sorry - "Expert") to do one. Owners  need a clear idea of what they want and what they need, because there are costs associated with making BIM demands. It is true there are some benefits they will get for no cost if BIM is used, but they need to know what these are, and which are the ones that will cost.

BIM is actually not a precise term - it means different things to different people (a topic I explored in previous posts What does BIM mean to you? and Its OK not to do BIM). In simple terms there are two versions: BIM as a design and construction process (which I prefer to call VDC - Virtual Design & Construct), and BIM as a facilities management process.
Owners will probably be more interested in the FM BIM, although they may want to use a design and construction team that utilises BIM because they believe they will get a better quality building.

This is where owners need to make their first decision, the options are:

• I want BIM for facilities management.
• I want BIM for a better quality building.
• I want BIM for facilities management and a better quality building.
• I don't need BIM.

BIM for facilities management

If it is decided to go for BIM for facilities management it is important to be clear about why it is wanted.
Doing it because it is a "good idea", is "future proofing", or "experts recommend it" will not cut it. Asking for BIM that "is suitable for" FM (don't laugh, this is very common) is so imprecise it is highly unlikely anything of practical use will be delivered.

How FM will be delivered must be defined:

• only raw BIM models provided for future FM use.
• provided to owner's in-house FM people.
• provided to owner's FM contractor/consultant.
• provided as turn-key system by the contractor, including hardware and software.

As-Built BIM model for future works on the project may also be desired. But this is different from FM, as an FM BIM Model is rarely editable. That is, it is very difficult to make changes to its geometry. Data can be changed, like what door lock is on a door, but that door can't be moved in the FM model (and normally you wouldn't want anyone to).
So if a BIM as-built is wanted the BIM model will need to be delivered in an authoring software format, like Revit, Archicad, Bentley etc, as a deliverable in addition to the FM model. If this is not clearly defined CAD as-builts linked to the FM model are likely to be delivered.

A note on IFC. IFC is often recommended to owners as "the" universal future-proof format. But IFC is NOT an authoring format. It is an exchange format that requires authoring software to convert it into their own format. Import an IFC file into Revit and it turns it into a Revit file. And currently very few authoring softwares do a very good job at this conversion, partly because IFC doesn't contain the sort of information that make authoring software efficient to use. Those that claim to do it well are closest to the IFC format - and therefore have the least authoring capabilities. The worst thing you can do is mandate an authoring software solely based on its ability to handle the IFC format.

And a note on COBie, another deliverable being recommended to owners. Construction-Operations Building information exchange (COBie) is standard for communicating information about assets in a building. It only contains data, not a 3D model of the building like IFC. It's usually delivered as a spreadsheet, which can be generated from BIM as well as filled in by human (so information not in BIM can be added), yet be automatically read by FM databases.
Mandating COBie without defining what is required within it will achieve little. It is like ordering a sandwich. If all you ask for is a sandwich, you are likely to get a Vegemite sandwich (but be charged for a caviar sandwich).
If all that is after is information already available for construction COBie requires little additional definition  and is probably the most cost effective way to get FM data delivered.
But an FM system must be capable of making use of COBie data as soon as the project is finished, otherwise that data will be out of date by the time it makes it into the FM system.

BIM for a better quality building

What aspect of better quality is wanted? It is important to keep in mind there may be costs involved, so only those that are actually needed, and there is an appetite to pay for, should be included.

Some areas that might be considered:

• better understanding of spaces and facilities by stake-holders (through 3D visualization) .
• better understanding of staging of works (if the project is in stages, e.g. a refit)
• a range of optimised building performances - thermally, solar, daylight, pedestrian flow, etc.
• cost control - ongoing measurement for costing.

There is a trap of thinking that forcing the design / construction team to use BIM will automatically result in a better building. More on that below.
Once a list is made it should be reviewed to ensure BIM can actually contribute to better outcomes, and at what likely cost. BIM can do a lot, but not everything.

Don't need BIM.

If  the benefits of BIM are not needed directly by the owner it is still possible to encourage BIM use for construction by requiring evidence the design / construction team are utilizing BIM.
But if  this choice is made it is important to ensure the selection process is able to identifying consultants and contractors experienced and capable of utilizing BIM in their processes. More on that below.

CONSEQUENCES OF OWNER'S CHOICES

What Information is needed?

If it is decided that BIM FM is wanted there needs to be a method to describe what information will be required to be embedded in the BIM model. If FM BIM data is to be delivered to the owner's organisation they must have adequate in-house expertise. There is no point delivering it to the person who works from a room full of filing cabinets and only use the computer to look at porn. If it is to a FM contractor they must be on-board early enough to contribute. At the end of the project it will be too late.

Who provides the Information?

The more information that is wanted the greater the cost. If information required is restricted to information likely to already be in the BIM model (i.e. that is used for construction) the cost may be modest.
But if what is wanted requires more information it is clearly more effort for some-one. If this is the case it is best to consider who is the best party to put that information in. Are the architects the best people to put costing codes in their BIM model for the costing consultant or contractor? Will they know what they are doing? Will they take sufficient care with what they are doing? And will making the consultant team input additional FM data slow them down and so impact on the projects timing? Would it be best to leave it to the FM team at the end of the project?
It is always possible to make some-one contractually obliged to do something, but that does not guarantee the best outcome for the whole project.

Selection Process

Including BIM will make selections processes more complex because an extra requirement has been overlaid. So an owners organisation's manpower demand and time to complete the selection process will increase.
By deciding to use BIM the range of consultant / contractors that can select from may be limited. It may also restrict the range of prices that can be obtained, and it may restrict the range of quality. This trickles down to sub-contractors and trades. If BIM shop drawings are mandated the range of sub-contractors that can be selected from may diminish. As BIM becomes more common this will be less of a problem, but it is important to be aware of it.
Forcing BIM on to consultants / contractors selected on low fees will not magically make them more skilled or competent. And do you really want them to learn BIM on your project? Sounds like a no brainer, but this scenario happens a lot.

Cost & Time

By its nature BIM requires more effort earlier in a project. A developed BIM model is required early in the project to get the most benefit, and it doesn't get put together without some effort. Owners need to appreciate that consultant cash flow requirements will tend to spread towards the beginning of projects. BIM shouldn't make any difference to contractor cash flow, but it might increase the percentage they apportion to preliminaries, particular if they are doing 4D (time scheduling) & 5D (costing).

The time taken by consultants to produce their work may increase, as they are actually doing more. Note, however, that research has shown construction times can be less on BIM projects, so the overall time to completion may not increase.

OWNERS GETTING WHAT THEY WANT

BIM Wash

The first thing is to be wary of BIM Wash. Particularly from academic 'experts' who may try and push processes that have yet to be used, or may even be impossible to achieve. I've experienced an 'expert' employed by a naive client who created a list of requirements that could not be achieved with the software mandated to be used on the project.
Consultants and contractors are also not immune to producing BIM wash. Beware of glossy brochures.

Consultant Selection

BIM can be learned, but beware of inexperience, or experience not relevant. I have seen surveyors claiming they could do an existing conditions BIM model based on their previous experience of importing Rhino models into Revit and calling it BIM.

It is important to pay particular attention to selection of the lead consultant (usually the Architect). A BIM savvy lead consultant can be critical to a successful BIM project.

Collaboration is talked about a lot in BIM circles, and whilst it is somewhat overblown, BIM works best when the consultant team collaborates on creating unified BIM models. It is hard to enforce collaboration, but one way to make it easier to achieve is to select consultants who use the same software. The software doesn't need to be mandated, but it is important to be aware that collaboration will be more difficult if consultants using different software are selected. But that doesn't mean that some-one who doesn't normally use a particular software should be forced to use it for the project. The difficulties they will experience learning to use it will overshadow any collaborative benefits.

It is best to select the project BIM manager from within consultant team, or make the lead consultant  responsible for their selection and management if appointed from outside the project team. BIM Managers are most effective when they work from within the project team, collaboratively, not as an external auditor only responsible to the owner. If oversight is desired a different method should be used (reporting deliverables, milestone issues, auditing, etc). The project team shouldn't be denied an effective manager of BIM processes.

Contractor Selection

Contractors don't so much create BIM as use it.  So their in-house BIM skills are not as critical as consultants. Contractors can always buy in BIM skills, including utilising those of the consultant team. They do however need to appreciate the benefits of BIM and integrate it into their processes.

It is important owners don't try and be a contractor. It is best when selecting contractors to get them to describe their BIM processes, not mandate what they should be. To ensure an effective BIM process let the contractor use processes they believe are worthwhile, and let them explain why they are beneficial. Not all contractors will use BIM the same way, but by getting bidders to explain what they do and why will enable a more effective selection process.

There is currently a tendency to request a separate price to 'do' BIM. My favourite is a hospital in Australia that had a 'BIM option at no additional cost' in its request for tender.  If a contractor is using BIM processes they are doing it for their own benefit.  By separating BIM out it invites costs to be put to processes that would have occurred anyway. I've seen a D & C project where the new owner wanted BIM on the project, so sub-contractors were asked to provide a price to 'do BIM'. Most were already doing it, or at least partly doing it, but of course they still put a price in.
The only reason to request a separate price for 'BIM' is for BIM deliverables that are in addition to what is normally provided for construction purposes, and that are actually required by the owner.

BIM Agreements

I don't intend to go into the nuances of contracts, but obviously it is important BIM expectations and deliverables are included in them.
The Australia AIA has produce a quite good discussion paper on this issue, BIM in Practice L - BIM, Legal & Procurement  (requires free registration), and I've written a response to it in my post A REVIEW: BIM IN PRACTICE - Legal & Procurement

One of the things BIM agreements try and enforce is collaboration. This can be problematic as some interpret collaboration as getting those involved with authoring BIM to put the work of others into the BIM model. Although BIM authors may be best placed to do this, they may not be best placed to take on the responsibility.
If the architect is modelling structural components, there needs to be a mechanism whereby the structural engineer is still responsible for the design of those elements and their correct representation in the model. This becomes critical, for example, if the steel shop drawer is relying on the BIM model to produce their work.

Collaboration is actually not about getting others to do your work, it is about getting others to do things that help you do your work. I explore one example of this in my post Should engineers model accurately?
Collaboration is difficult to mandate, but including clauses on fulfilling reasonable requests from others on the project team might help. But it is still important to ensure that responsibility remains with those with the appropriate expertise.

Is IPD necessary?

In short, No. There is a lot of talk about true BIM not being possible unless Integrated Project Delivery (IPD) type contracts are used. This is simply not true. The advantages of BIM are there for any contractual arrangement.
There may be other reasons you might want to use IPD, but don't do it just because you think the BIM will be better.

The BIM Brief

Critical to owners getting what they want is how it is described to others. What is needed is a clear, consistent method that flows through the whole project from start to finish.
The best way to do this is to integrate owner requirements into a project BIM Management Plan.
But I don't mean a single BIM Execution Plan as advocated by the many current BIM guides. It is unrealistic to expect a single document to encompass all BIM requirements for every participant over the whole life of a project.
What I mean is a series of inter-related documents that together form the Project BIM Management Plan. A topic I explore in my post Single project BIM Execution Plan: a good idea?

The first of which is the BIM Project Brief. This is a document the owner authors and that sets out what their BIM deliverables and BIM expectations are.

A BIM Project Brief (BPB):

• is a short, high level document.
• is created before project starts and anyone is appointed (and ideally included in consultancy bid documents).
• sets out BIM deliverables only, avoids describing how they are to be achieved.
• describes required content of the other BIM plans that make up the BIM Management Plan.
• should never need to be revised (unlike some of the other BIM plans).

The BPB should be the only, and guiding, document for BIM requirements on the project. Other documents, like consultant agreements, construction contracts, FM contracts, and BIM plans should refer back to this document.
Because BIM means different things to different people it is not uncommon for a different definition, and therefore intent, to be used in the various contracts and agreements used on a project. The classic is an FM contract that assumes FM data is already in the provided BIM model, but there is no requirement in consultant or contractor agreements to include it.

What does a BPB look like? I've explored it a little in my previous post BIM for Owners: the BIM Project Brief  but I'll flesh it out more in my next post.

I'm also hoping to consolidate my ideas at this years RTC Australasia conference in Auckland 16th to 18th May, where I'm presenting a talk called "BIM Execution Plans: Avoiding the Noose".

What is this thing called LOD

There still seems to be some confusion about what LOD levels mean, and how they should be used. I must say I have difficulty relating what I do and what I need whenever confronted with filling in an LOD table. If they are this difficult why are we using them? Are they really useful, or just a waste of our time?

HISTORY OF LOD

From what I can gather LOD was developed by Vicosoftware, a software company that produces construction costing software. They saw the advantages of costing straight from a BIM model, but had a problem. How do you tell how accurate, or how definitive, the model elements you are connecting to in the model are? Traditional methods of costing have a human between what was being measured and the way it was being measured. But automatic take off from the BIM model doesn't.
So they developed the concept they call "Level of Detail". A measure of how definitive an element is in terms of costing it. So LOD 100 meant not very definitive, an area or volume rate is accurate enough, LOD 200 you can assume the number of items in the model is correct, but use an estimate for each, LOD 300 items are identified and actual cost can be used, LOD 400 is a measure what has actually been supplied so can be used to assess payments.
Sounds very sensible, very precise. But then the AIA (American Institute of Architects) decided that this system would be a good one to apply to all uses of a BIM model, from energy analysis to 5D programming. They sensibly renamed it "Level of Development" because "Level of Detail" could get confused with the amount of information, rather than the decisiveness of the information. Although both still have an acronym of LOD so the two continue get confused (more on that later).
Others have taken up the concept, and today it has become one of few common BIM concepts that is kind of understood by all  (more on that later).

WHAT EXACTLY IS LEVEL OF DEVELOPMENT

LOD, as in "Level of Development", is a measure of how seriously you take the information represented by a BIM element. It is not necessarily a measure of the amount of information, although obviously there must be enough information to satisfy the LOD level it is at. It is also not a measure of the amount or accuracy of graphical information. The appearance of a BIM element is only one piece of information about that object, and usually the least important. A contractor doesn't need to know what a desk looks like to order it, nor to place it in the building. But they do need to know what the manufacturer and model number is. Others may need to know its dimensions to coordinate with things around it, but they too do not necessarily need to know what it exactly looks like.

Therefore LOD levels for a chair might go:
LOD 100 = there is a chair
LOD 200 = there is a chair that has nominal space requirement of 500x500
LOD 300 = there is a chair with arm rests and wheels
LOD 400 = manufacturer and model number.
LOD 500 = manufacturer and model number, supplier, date purchased

or in general terms:
LOD 100 = there is a thing
LOD 200 = there is a thing about this size
LOD 300 = there is a thing with these functions and options
LOD 400 = it is this particular thing.
LOD 500 = this particular thing provided by this person on this date.

The purpose of an LOD table is that it tells others what information they CAN USE. To put it another way, it is a measure of the certainty, or confidence, of that information. So even if a chair in the model contains information that would satisfy LOD 400, only the portion of that information that satisfies LOD 100 can be  relied upon with any certainty. This means a chair family from a manufacturer could be used at LOD 100, but everyone knows (by referring to the LOD table) that this particular chair is not necessarily the one that will be actually used.

LOD is also a measure of progress. At LOD 100 there is obviously more work to do to reach LOD 300. In that sense it is like the traditional percentage complete of drawings. Assuming LOD 500 is 100%, then LOD 100 = 20%, LOD 200 = 40%, LOD 300 = 60% etc.
Except LOD contains more information. It tells you how decisive each element is, not just how complete its representation is on a drawing. It is more useful to know that on a plan the floor is 60% complete (LOD 300), the walls are 50% complete (LOD 250) and the service ducts are 40% complete (LOD 200), rather than the whole drawing is 50% complete (the average of all elements).

SO WHAT IS LEVEL OF DETAIL

Level of Detail is a measure of the amount of information provided. Because it is only a measure of quantity, the underlying assumption is that all provided information is relevant to the project and so can be relied upon with certainty.

Because of the confusion between the two LODs, most BIM guides and plans use other terminology for Level of Detail.

Some examples:

CIC (Penn state)
"Information Level of Detail" - AKA "Info"
A - Accurate size & location, including material and object parameters
B - General size & location, including parameter data
C - Schematic size & location

USACE M3
"Grade"
A - 3D + facility data
B - 2D + facility data
C - 2D, part of an assembly or text description

AEC (UK) BIM Protocol
"Graded Component Creation"
G0 - Schematic
G1 - Concept
G2 - Defined
G3 - Rendered

USACE is probably based on the CIC definitions, but customised to suit the current abilities of BIM software and the consultants they use. I suspect it may change over time. The AEC (UK) grades include 'Rendered' which is purely graphical, which seems to suggest it is a measure of graphical detail only. Their accompanying diagram shows 3D representation, although presumably 2D only would be acceptable.

LOD TABLE STRUCTURE

Typical LOD tables are a 2 dimension matrix, down the left side are Model Elements, across the top the first heading is project stage or Project Milestone - (e.g. Concept; Schematic; Documentation; Construction; As Built), below that is LOD, and any other measurable, like MEA (Model Element Author), Grade (Level of Detail) etc.

Some are others loose and flexible (like AIA E-203):

some are incredible long and complicated, (like Australia's NatSPEC):

The most common other addition is "Model Element Author". This is, as the name suggests, the authoring party of an element. Typically this is the structural engineer for structural elements, mechanical engineer for ductwork etc. It has nothing to do with LOD but is useful information as is sets out who does what. My reading is it sets out who is the creator and responsible party in the BIM model, and not necessarily contract deliverables like drawings and schedules. For example the architect may be the MEA of structural elements because the structural engineer won't model accurately enough for the architect's purposes (see my previous post Should Engineers Model Accurately). But of course the structural engineer is still responsible for structural contract documentation for construction.

Other additions include the Level of Detail (AKA Grade or Information), and really anything else that may be useful. In the past I've included method of delivery which provides a timeline for when information gets put into the BIM model.

BUT THEY AREN'T CALLED LOD TABLES

Although I am using the term here there is actually no such thing as an LOD table because LOD is used in tables with other things, and for slightly different purposes. Some of the names for tables include:
Vicosoftware              - "Model Progression Specification"
(US)AIA                     - "Model Element Table"
USACE                      - "Minimum Modelling Matrix" or "M3"
Veteran affairs (US)  - "VA Object Element Matrix"
NatSpec                    - "BIM Object Element Matrix"

So really LOD table is a generic term to describe to tables that include LODs. Is any name better than others? Again I think Vicosoftware got it right. LOD tables may describe other things, but LOD fundamentally describes how information in a BIM model will progress. How much information will be usable at each stage or milestone of the project. They use "Model Progression specification", but "Model Progression Table" or "Model Progression Matrix" are just as good.

DEVELOPMENT or DETAIL - IS THERE A DIFFERENCE?

Level of Development and Level of Detail are closely related. You can't have a certain Level of Development if the Level of Detail doesn't exist.
Only defining the graphical level of detail seems pointless. It doesn't matter how realistic a chair looks, if you don't have the manufacturer and model data no-one can cost or order it. It just looks pretty.

The level of graphical appearance doesn't necessarily progress during a project, it may actually go backwards. The realities of a project usually mean you use the highest Level of Detail at the beginning when there is the lowest Level of Development, as this is when you use rendered images to sell the design to your client and stake-holders.
And to keep the complexity and size of your documentation model low during documentation you want to use a low Level of Detail, even though the Level of Development is quite high.

Of course Level of Detail could explain more than just graphical appearance, but it still doesn't communicate what everyone needs to know - what information can I use with certainty?
And is there any point defining Level of Detail if it is required for Level of Development? Probably not.

To avoid confusion we all should always use the acronym LOD for Level of Development, and use some other term for level of detail. "Grade" is used by a few BIM guides, but it not very descriptive. To keep the metaphor going how about "Depth of Detail" (DOD), where each LOD is a level of certainty passing through the Depth of Detail.

The diagram on the left below shows what is meant when you use Depth of Detail only, the one on the right when you use Level of Development (which by inference includes DOD).

IS THERE A POINT TO LOD?

The original restricted use for Level of Development (LOD) developed by Vicosoftware makes sense, but when you apply it to a cover all uses for BIM information it starts to loose clarity. The reality is LOD levels means different things for different uses, so now you need another table - the BIM Uses table - to explain what uses each LOD level can be used for.

LOD makes sense if you link it with model elements (by putting it in a parameter for example) so your costing software can extract LOD data directly from the model. But when it is listed in a separate document where is the advantage? It seems strange (and not BIM like) to keep LOD requirements in a place separate from where those creating the information that satisfies those requirements are working. Shouldn't it be part of the model accessible to all those working and using the model, not in a separate spreadsheet or word processing document?
Indeed is a better use for LOD one where it describes what level of development (or certainty) an element is after the fact? Users nominate the LOD of elements they are working on as they go. As element information becomes more definitive it's LOD increases. Then LOD would be in the model, and extractable as a schedule.

When first explaining LOD to a director (an architect) his initial response was "you mean LOD is the same as a project stage". My first reaction was "well, yes and no". But when I thought about it, yes it is. By separating LODs into different project stages it is just stating the obvious. Of course at concept stage most things will be at LOD 100, at As-Built Stage LOD 400. There will be some things at different LODs, but is it worth filling in a massive table for these few exceptions?

Which leads to me to my other reservation. Are they serious when they say every model element type has to be listed with it's own author and LOD? And use Uniformat or Omniclass or Masterformat? It is not just the massive amount of work to do it, who will ever refer to it? Do they really think the mechanical engineer is going refer to it to find out if he has to model duct work because some-one else might be going to do it?

Going by the current BIM guides and standards an LOD table is both over complicated and yet imprecise. A lot of effort for little practical benefit. If people just followed the BIM guides and standards there is a real danger LOD tables will be a "tick the box" task. Done once and never referred to again.
But an LOD table could impart some useful information. What is that information and what is it the best way to communicate it?

WHAT AN LOD TABLE IS TRYING TO COMMUNICATE

An LOD table is an attempt to record agreed (whether voluntarily or not) responsibilities around a BIM model.  As mentioned above, it only relates to the BIM model, not other deliverables or responsibilities.

For each part of the BIM model and at each stage of the project we need to know:

• Who is the author and responsible party.
• What is in and not in the BIM model.
• How much of the information embedded can be used with certainty.

Obviously the complexity and amount of detail required for each of these will be different for different types and sized projects. The level of sophistication achievable will also depend on the BIM experience of the project team. So to have a one size fits all approach doesn't make sense.

THE LOD CONCEPT

So should we throw LOD tables out and come up with a better alternative? Many have made the same suggestion and even come up with alternatives. I've seen what used to be LOD tables have LOD removed and replaced by percent complete, because everyone understood what percent complete means. Some have replaced LOD with Depth of Detail (like USACE and AEC(UK)), because that is easier for people to visualise.

But I think LOD is a good idea - as a concept. It holds more information then Depth of Detail or percent complete, but is still a simple concept. I don't think it is a good idea as a 'standard', if applied too rigorously LOD tables quickly become irrelevant, and a management burden on projects.
So, a bit like the definition of BIM (see my previous post What does BIM mean to you?), it is best to treat LOD as a broad concept rather than a precise tool. We all need to understand what it generally means, but still appreciate it means different specific things to different people, and on different projects.

FLEXIBLE LOD TABLES

The (US)AIA E-203 Document uses LOD and MEA (Model Element author) in its Model Element Table. But it is not highly prescriptive about how that table might be constructed. Although Uniformat is suggested, it is not compulsory  ". . . there is no single best system for classification of the Model content.", and "the user is also free to delete or alter the CSI structure and insert another guideline or a firm specific or project specific model element structure."

The structure of LOD numbering, broad definitions 100 apart, leaves plenty of scope to slot in extra numbers with special meanings for your project. I've used 250 and 350 before to overcome issues around services construction design being done by D & C contractors.

The (US)AIA E-203 is also not strict on LOD use itself, suggesting items not modelled be identified as "NM". This could be expanded to code where the information can be found.
And just to make it really flexible the Model Element Table has a notes column for each stage plus a notes column for each model element.

I believe the (US)AIA approach is the right one. Use the broad structure and concept, but tailor it for your own purposes.

HOW TO MAKE LOD USEFUL

The best way to make LOD useful is to think about how you can make LOD meaningful to your project and the project team, or your office if you are the BIM manager.

If you are required to do an LOD table say you will comply the (US)AIA E203 document, rather than one of the other BIM guides. It gives you pretty much the freedom to create an LOD table any way you like.

Don't be afraid of doing a really simple LOD table, particularly if it is your first one. If the project team is using Revit there is no reason you couldn't list Revit categories as your building elements. If you are comfortable listing trade packages, do that.

Create your own LOD levels. That's why the standard ones are so far apart, it is designed to have other, in between levels. Just make sure you define what those levels mean.

Do multiple LOD tables if it helps. I do a simple short one for sign off by directors, owners and sometimes the contractor, and then a more elaborate one (which aligns with the simple one) for the project team. By taking this approach you could, for example, make the AIA E-203 Model Element Table simple, so that it only sets broad requirements (and therefore flexible, always a good idea when signing a contract), yet still have the opportunity to be more precise when managing the project team via a more detailed table.

And finally think of other uses for LOD. Remember, it is a concept, not a rule. Why not have an LOD parameter for objects in your model to track progress and work as a QA check?
For example:
- LOD 290 = preliminary construction defined;
- LOD 292 = checked for functional requirements;
- LOD 294 = checked for fire requirements;
- LOD 296 = checked for smoke requirements;
- LOD 298 = checked for acoustic requirements;
- LOD 300 = final construction defined;

Let's take ownership of LOD and make it our own.

Postscript:
A discussion on the [US]AIA E203 document LOD defintions can be found in my post
 LOD, are we there yet.

Bored with BIM? Need a present for that special woman in your life? The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, fashion and ... men. Book one of the series, "Awakening the lost woman", is available now on Amazon,  Google Books,  Kobo  and  iBooks.