What is the use of BIM Use

In my last post on LOD I touched on "BIM Use" as used in the [US]AIA E203 document. In that post I wondered why certain BIM Uses are not mentioned. But on reflection I now wonder what the concept of "Authorized BIM Use" is, and what it is trying to achieve.

What is "Authorized BIM Use" 

The obvious meaning of "Authorized BIM Use" is the use that elements in a BIM are "authorized" to be used for.

In the [US]AIA G202 document this is described as:

4.4 Anticipated Model Authorized Uses.
Indicate below the anticipated Authorized Uses of Models on the Project, which Authorized Uses will be agreed upon by the Project Participants and described for each LOD in G202–2012.

As you can see each "Authorized BIM Use" is associated with each LOD. So "Authorized BIM Use" is a requirement for properly describing an LOD. Note also that the assumption is BIM Uses are "agreed upon", so they are not necessarily imposed by the owner, but real Uses by actual participants.

It appears the idea is that when you select an LOD level that applies to certain elements, it is necessary to say what those elements can be used for.
I assume this is because the [US]AIA has decided that it is not enough to say that an element is "graphically represented in the Model with a symbol or other generic representation" (LOD100), but must add these definitions:

1. Analysis. The Model Element may be analyzed based on volume, area and orientation by application of generalized performance criteria assigned to other Model Elements.
2. Cost Estimating. The Model Element may be used to develop a cost estimate based on current area, volume or similar conceptual estimating techniques (e.g., square feet of floor area, condominium unit, hospital bed, etc.).
3. Schedule. The Model Element may be used for Project phasing and determination of overall project duration.
4. Other Authorized Uses. Additional Authorized Uses of the Model Element developed to this LOD, if any, including Authorized Uses identified or required by uses set forth in Section 4.4 of E203–2012, are as follows:

It seems to make sense

So apparently if you are defining the level of resolution or certainty of an element you also need to say for what purposes this certainty applies to.

And the act of defining "Authorized BIM Uses" means that if a BIM doesn't contain information needed for that particular use the BIM author can be forced to provide it via contractual coercion (assuming they signed up for it).

So there are two purposes for including "Authorized BIM Use" in LOD definitions:

1. defining what information in a BIM can be used for,
2. ensuring BIM modelling meets the requirements of others.

But is "Authorized BIM Use" rational?

Lets start with the fact that there is a separate BIM Use definition for each LOD. There are 5 LODs (6 if you include LOD350), times 4 BIM Uses for each equals 20 (or 24) separate "Authorized BIM Use" definitions as standard in E203. Possibly more if there are more "Authorized BIM Uses".  That is a lot of definitions.

The next issue is although LOD relates to elements and not the whole model, BIM Uses are usually deliverables that apply to the whole model. That is, for example, a use like Cost Estimating is not done as a continuous exercise, it is associated with project milestones. So strictly speaking there should be different BIM Use definitions per each LOD per each Project Milestone.
Or is this considered unnecessary because there is an assumption an LOD level matches particular milestones? (LOD100 = Concept estimate, etc). Surely not, that kills the concept of LOD not applying to the whole model.

And if a BIM has elements at different LOD levels at a particular time what does that mean for a BIM Use? If a thermal analysis is done and the floor is LOD 400, the walls are LOD300 but the roof is LOD100 what does the BIM Use definitions mean? There are three different BIM Use definitions applying to the analysis. How is that helpful?
Or is the assumption that for a particular BIM Use certain LOD levels must be met. So in the example above floor, walls and roofs must be LOD300 before the BIM is ready for thermal analysis. But doesn't that mean different milestones for each BIM Use will be required? If that is the case why associate BIM Use with an LOD level? Why not just associate BIM Use with a milestone?

So I really don't understand how BIM Use applied to LODs is supposed to work.  But more concerning is how are "Authorized BIM Uses" decided and what their implications are.

Problems with "Authorized BIM Use" in practice

There are a number of issues that arise when trying to apply "Authorized BIM Use" to the real world.

Insufficient Information

As I pointed out above the [US]AIA E203  document assumes project participants will decide what "Authorized BIM Uses" will be for a project. That is fine in theory but my experience with real projects is that not all project participants are on board when the BIM agreement is signed. The architect usually starts before anyone else, the quantity surveyor may be there depending on the contract type, then the consultant engineers, and the contractor doesn't appear till way past the time most have finished their BIMs. So BIM Uses are a guess as to what future participants may or may not want, or be able, to do. And of course there is no-one to offer any expert advice on specific requirements that those BIM Uses may require.

The assumption in BIM agreements is that the 'details' will be worked out later on when the BIM Execution Plan is done. But how do authors progress their BIMs if specific requirements are unknown when they start their BIM? How do they scope the amount of work that will be required so they can work out what their fee should be and how long it will take them?

Restricting BIM Use

There is an implicit assumption that by defining "Authorized BIM Uses" that other uses, i.e. those not explicitly defined, are NOT authorized. Why? Why can't anyone use a BIM for any purpose they like? Why do they need the BIM author's permission?

Certainly some-one using a BIM for their own purposes needs to be confident the information in it is accurate and complete enough for their purposes, but isn't that what an LOD level tells them?

What would the author know

And why would a BIM author (typically an architect or engineer) know what is required for some-one else's purpose? As an architect I have no idea if my BIM is adequate for cost estimating because I don't know what an estimator or their software requires. That is not my area of expertise. I can not warrant that my BIM is "suitable" for cost estimating, my Professional Indemnity insurance won't cover me for it. All I can say is I have modelled elements I am responsible for to a particular standard and they have a particular LOD level.

Other's requirements interfering with my requirements

The inference is that an author's BIM must be "suitable" for other people's particular BIM Uses. But what if the requirements of others prevents the author from using the BIM for their own purposes?
On a recent Linkedin group discussion on Correct Modeling Practices an estimator listed their requirements for a Revit model. One was to model floor penetrations as an "opening object", presumably so their software can extract accurate quantities. But we model floor penetrations with a component that cuts a hole in the floor. By doing this we can tag each penetration, embed what its purpose is in the component's data, and produce schedules of penetrations. All this greatly facilitates coordination, one of our responsibilities. Are we expected to forgo these benefits to fulfill our responsibilities under E203?

Allied with this problem is what if a requirement for one BIM Use conflicts with another Use? The estimator requires penetrations to be modeled as opening objects but the scheduler requires them to be modelled as shaft objects?

What is "Authorized BIM Use" really trying to achieve

Lets go back to the purposes of  "Authorized BIM Use":

1. defining what information in a BIM can be used for,
2. ensuring BIM modelling meets the requirements of others.

I believe both these purposes are misguided.

Is it really necessary to define what information in a BIM can be used for? Why do we think we need to restrict what a BIM can be used for? People are coming up with new and novel uses for BIMs all the time. Indeed there may be Uses that don't exist or are impractical when a project that goes for 2 to 5 years starts.

Ensuring BIM modelling meets other's requirements is not practical. Only the user can know what their requirements are, and quite frankly, their requirements may be unreasonable.


What is actually required is a way to ensure minimum modelling requirements are met. That the normal deliverables of an author is provided in BIM form that is known and consistent.
Recognition that it is the user of a BIM who has to work out how to utilize the information it contains, it is not the BIM author's responsibility to provide a "ready to use product".

And there is absolutely no need to tie this in with LOD definitions.  LOD may play a part but there are plenty of other ways to define minimum modelling requirements. Just look to the USACE M3 for a real life example.

Conclusion

"Authorized BIM Use" has no place in LOD. It is not necessary for the LOD concept to work in practice.

It is in fact an example of confusing Level of Development with Level of Detail, or degree of certainty with amount of information. "Authorized BIM Use" in the [US]AIA E203 document is an attempt to define minimum modelling requirements, which is a measure of amount of information, it has nothing to do with degree of certainty.

So what replaces "Authorized BIM Use"? - ways of defining minimum modelling requirements - an issue I think is becoming critical to practical use of BIM.
A topic for a future post.

LOD, are we there yet

After going through the [US]AIA  E203 document Draft (actually the G202 where LODs are described) and BIMforum's LOD Specification I got a bit excited. Maybe, just maybe, LOD is maturing and might actually be useful in a practical way.

To be honest it was Brian Renehan's excellent blog post Developing LOD (Level of Development) that made me think progress had been made. It clearly set out the differences between the original E202-2008 and the new E203-2013.

Mind you, the 20 odd pages that the [US]AIA Digital Practice Documents Guide took to describe LODs left me with the impression it shouldn't be this complicated. So I thought I would try and write a simplified, concise description of LOD. But when I studied it closer I found I couldn't follow the way some things were supposed to work, and felt there were some things missing.
I think I understand what is being attempted, but am not confident my reading of the literature is correct. And if I am having trouble understanding it, there must be others out there in the same boat.

So before attempting my "LOD for Dummies" post I thought I should write about my concerns to see if they are shared, or are, in fact, completely wrong.

Isn't BIM about Data?

In the [US]AIA E203 under every LOD description (except LOD100) there is the sentence:

 "Non-graphic information may also be attached to the Model Element".

"may"? I would have thought "non-graphic information" - i.e. data - would be a requirement for it to even be called BIM.

How do you derive information if there is no data, just geometric modelling? I call that 3D drawing, not BIM.

LOD100 is silent on "non-graphic information", but presumably it is not a requirement just like all the other LODs. Yet there is an assumption information can be "derived" from areas. Yet isn't area "non-graphic information" ? After all you can create a graphical representation of say a floor, without an area attached to it. That is what CAD software does.

And why are elements to be "graphically represented"? Don't we want them to be geometrically represented? Something that represents the critical 3D shape and size of elements. Strictly speaking an element can be "graphically represented" by a 2D symbol.

I find this approach strange and unnecessary. Why would you even distinguish between graphic and non-graphic information? The point of BIM is that they are tied together. You might as well use CAD and spreadsheets.

LOD 100 - how does it work?

The big one for me is I really could not follow how LOD100 would work in practice.

To recap G202 says:

“2.2 LOD 100 – Model Element Content Requirements.
The Model Element may be graphically represented in the Model with a symbol or other generic representation,
but does not satisfy the requirements for LOD 200.
Information related to the Model Element (i.e. cost per square foot, tonnage of HVAC, etc.) can be derived from other Model Elements.”

Firstly I don't see how "graphically represented in the Model with a symbol" helps anyone. Unless that symbol has data that can be extracted it is pretty much invisible to other softwares. There seems to be confusion between drawings and BIM.

But data is not mentioned as I discussed above. Shouldn't there be a requirement in the LOD100 description for gross quantities such as areas and volumes? How can estimating be done without it? Or is there an unsaid assumption all BIM software will have this anyway?

Perhaps the most significant part of the LOD100 description that it "does not satisfy the requirements for LOD 200". That is you allocate LOD100 to everything in the model that doesn't satisfy any of the other LODs. But of course that means LOD100 can't really be used for anything. You don't know if the element has been put in the BIM to just satisfy a documentation requirement, or as a work-around, or is actually a representation of something real. So I don't think that is the intention.

I don't understand what the process is for identifying information "derived from other Model Elements”. The example of lighting being costed on the basis of floor area is given. So OK, lights are not modelled, I get that. Therefore they are not in the BIM.
But how do you communicate that the quantity of lights is to be derived from the floor area? Is it something you put in the LOD table, or is there an expectation that data associated with floors includes information about lights (and all the other things derived from floor areas)? But then why does this need to be explained in the BIM at all?

Surely it would be simpler to say lights are not in the BIM model and leave it at that. In the costing example the estimator then knows not to rely on the BIM for information on lights, it will have to be calculated within the estimating process using other information. There is no need for the BIM to indicate what that other information is, as the costing expert the estimator makes that call. It is not up to the BIM to tell anyone how to do their work. It is just a resource, and the LOD table merely tells people what is in the BIM and how reliable it is.

So I really don't know what I am supposed to do to comply with an LOD100 requirement.

I understand it is supposed to provide notional information, but I can't envisage how the [US]AIA G202 definition might be used on a real project. 

LOD 500 - confused?

LOD500 has caused some confusion. Certainly Brian Renehan writes about it in his blog post.

To recap the [US]AIA definition in G202 is:

"2.6 LOD 500 - Model Element Content Requirements.
The Model Element is a field verified representation in terms of size, shape, location, quantity, and orientation. Non-graphic information may also be attached to the Model Elements.”

One area of confusion is BIM Use. By LOD500 uses like clash detection, time sequencing and costing are no longer in play. So it makes no sense to say an LOD500 element has these BIM Uses. About the only use left is Facilities Management. Yet FM is not a BIM Use the BIMforum LOD specification or [US]AIA G202 includes by default (although that doesn't mean it couldn't be included).

The other is the lack of definition around data. It may not be necessary to upgrade the element's graphical representation at all, because it already meets the LOD 500 definition. All that may be required is that data associated with the model element is upgraded to describe what was built or installed. But you wouldn't get that from the definition because non-graphical information is optional.

Like LOD100 I am pretty sure I understand what is being attempted, it is just not being explained very well.

Missing LODs

Not Everything is BIM

There is no method to describe things that aren't to be used even though they are in the BIM. Despite what others think we BIM authors don't create our BIM models purely for their benefit. At the moment our main purpose is the generation of printed drawings and schedules. Our BIM models also end up with design options and other deliverables (like GreenStar or LEED). This means our models contain things of no interest to anyone else, or the proscribed BIM uses. But how would they know?

Not Everything is in the BIM

The other missing descriptor is that there is no method to describe things that aren't in the BIM. In the [US]AIA guide there is a suggestion to use 'NM' (not modeled). But I think it should be integral to LOD descriptions.  It is just as important to know what is not modelled as to what is.  There should be an explicit way to say something is not in the BIM, not just a 'suggestion'  in the guide.

Is Creation of Construction Documentation a BIM Use?

One of the uses we are all using BIM for at the moment is for the creation of construction documentation - drawings and schedules.

Yet this is not mentioned as a BIM use. I'm not sure why not.

No-one builds straight from a BIM model. Some construction tasks might make use of the BIM model, like laser set-out and other surveying tasks, but drawings and schedules are still required to explain how, and scope what, is to be built.

Certainly authors of BIM models are using their model for this use. But could we say others are utilizing BIMs that are not their own for their documentation?

Possibly not. I can't think of an example where this happens. You might use some-one else's BIM for design or analysis (engineering or otherwise), but generally not for producing your drawings or schedules. If you did you would effectively be taking information some-one else is responsible for and presenting it as work you are responsible for. Something I would have thought should be avoided.

But using BIM for the creation of construction documentation is a valid use, and one that needs to be encouraged. I am constantly surprised at how few in the AEC industry use BIM to generate schedules, how many details are still done in isolation using CAD.

At the end of the day if the construction documentation doesn't match the BIM that BIM is going to be pretty useless, whether you are using it for design, analysis or anything else. Which is why this should be addressed as part of LOD. I always include "creation of construction documentation" as a BIM use. It may only be the authors using their own BIM for this use, but it needs to be stated, and participants need to be held accountable if they agree to it.

End of a Milestone is Too Late 

The [US]AIA E203  guide rightly says milestones are not equivalent to project stages (concept, schematic,  documentation  etc.). 

Their example LOD tables put these milestones are across the top which puts a practical limit on how many milestones there can be (otherwise they won't fit on a printable page). 

[US]AIA G202 LOD Table

This infers there shouldn't be that many of them, and further that all elements will probably meet the same milestones.

But the reality is BIM deliverables don't necessarily all happen at the end of a project milestone, and don't necessarily involve every element in the project. It is more likely certain elements will require a level of resolution before other elements can progress.
For example milestones might be the week number of a project stage, or if the program is not sufficiently defined divided into, say, 10 parts. Then certain elements can be targeted to reach their LOD level earlier or later.

 Brian Renehan suggested an alternative LOD table format in his blog post Developing LOD (Level of Development). I've created an example of a similar table below.

after Brian Renehan's LOD table

Milestones (MS) are a column, and LODs run across the top. LOD tables will then be a fixed width (i.e. LOD100 to LOD500) but allow a varying number of milestones per element. 

Certainly the LOD table structure in the [US]AIA G202 will work if there are limited BIM milestones, but I believe Brian's alternative provides greater flexibility.

Am I wrong?

Generally l believe the [US]AIA E203 Document conception of LODs is good. Restricting LOD 400 to only fabricated elements makes practical sense. As does utilizing LOD 500 to identify only those elements actually requiring field verification.
The BIMforum Specification has clear and concise descriptions of the [US]AIA LOD definitions, along with a sensible addition of an LOD 350 for installation information.

And to be clear I am not commenting on the whole [US]AIA  Digital Document set, only the LOD part. Nor do I consider it to be the only definition or only use for LOD. The LOD concept has a wider application than a single legal document in one country. But the [US]AIA E203 Document is a good starting point.

So I am supportive of the [US]AIA and the good work they have done. It is just that there are a few things that I believe don't quite seem clear enough to make practical use of LOD.

I'd be grateful if anyone can put me straight.

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.