29 March 2013

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.


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.


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:

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

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.

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


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.


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.


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


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.


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?


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".


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.


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).


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).


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 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.


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".

16 March 2013

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?


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.


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.


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".

01 March 2013

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?


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).


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).


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

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.


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.


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.


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).


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?


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.


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.


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.


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.

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.