25 January 2014

Four Things BIM Doesn't Do

If we make the assumption that BIM contains all information about a project (or the 'index' for locating information), what is missing?  What stops us being able to issue a BIM model without drawings? (a question I asked in my post  Can BIM alone be used for Construction.)

I'm not just talking about lack of software functionality, but missing from current BIM processes.
I don't believe these missing things are intractable, a reason to not use BIM. The problem is that they don't seem to be a part of BIM discussion, let alone being addressed.

A BIM model is in theory a virtual representation of a real building. The assumption is that as long as everything is represented that is all that is required. Any shortcomings in practice is purely due to a lack of detail in the model, or poor modelling practices.

Keep in mind here that a BIM Model is not drawings. Currently we use our BIM softwares to produce drawing sets that are contract deliverables. But what about the utopian future BIM evangelists say is inevitable? What would a fully mature BIM model be like?
  • All information is in the model, one only needs to 'zoom in' to expose more detail.
  • Dimensions can be extracted from anywhere in the model.
  • All information about individual elements is available via the parameters they contain (which may include links to data outside the model).
  • Drawings are not created by the model author or contained in the model. Users create their own as they need them.

Sounds pretty good, not unlike many descriptions of what BIM is. But this is the description of a fully mature BIM model, once all the various authors and contributors have done their work.

BIM models don't start out with such comprehensive information. They can't. All construction projects are a series of decisions based on previous decisions. Decisions are iterative, a decision may cause a previous decision to be revisited and changed. Interesting the original intent of Revit (an acronym of 'Revise' and 'it') was to make it easier to change design documents, making optimization of designs more practical. Only later did Autodesk re-badge it as a BIM tool.

So when this description of what a BIM model should be is assessed against requirements during the design phase it falls short. The tools to communicate, manage and store information around decisions are missing.

So what are the four big things BIM doesn't do for designers.


Although everything is not known in precise detail during design phases there is still information that needs to be communicated. Design intent, what is important and what is not. What requirements are, and which of those are critical, optimal and desirable.

Assigning a wall as 'generic' only says a decision hasn't been made. It doesn't say what the limitations for making a decision are. And it only applies to individual elements, not to groups of elements.
Another example is dimensioning. Not all dimensions are equal in importance. The clear width of an escape stair is more important than the width of a store room. How do you convey this in a BIM model where the recipient extracts their own dimensions?

Rob Snyder, an architect and software developer at Bentley, has attempted to provide a solution. In his own words:
"A model is itself informational, while it 'lays out' an environment of information. Within that environment, we draw attention to specific things and instruct people to look at those things and to do something. These 'drawings of attention' are statements.
There are models and data. These are 'environments'.
There are drawings. Drawings are 'statements'.
I think of it like this - a statement is any means of drawing attention to something specific within an environment, and then saying something about that thing. In AEC, this has conventionally been done by making a drawing. A drawing draws one's attention toward something specific, and says something about it."
Rob Snyder, LinkedIn discussion Oct 2013

Bentely's solution to this problem is 'hypermodeling' - software functionality that provides links within a model to drawings, typically 2D details, although in practice the link can be to anything. It is basically an implementation and extension of web 'hypertext' (now usually referred to as 'links') to modelling.
What it does is provide visible 'tags' in the model that indicate points of importance, complete with links to why it is important.

Graphisoft have a similar solution, which they call 'Hyper-models' under the 'BIMx' brand name. Similar to Bentley it provides links to 2D drawings from within a 3D model.

Is this THE solution to the problem of intentionality?
Snyder, and Bentley's implementation privileges 2D drawings. Which is not surprising considering Bentley's 'evolutionary' approach of combining CAD and BIM. Graphisoft's approach is not so much a solution to intentionality as simply another way to access drawings.

But conceptually there is no reason the idea of hyper-modelling has to privilege 2D drawings. A tag could link to, say, an exploded 3D detail, a render of the architect's design intent, or a performance brief for a mechanical system.


BIM models are precise. Computer software requires precision. But the real world is not that precise, particularly where humans are involved.
It is not possible to always measure to the millimetre on a building site. Not all materials are uniform in size, even manufactured ones. Materials and elements move; concrete shrinks, bricks expand.
I discussed this issue in my post Accuracy vs Precision, but in this post my concern is the inability of BIM softwares to cater for the representation and management of tolerance.
Designers - architects and engineers, have to allow for tolerance in their designs if they are to be constructible.
But how do they do this with software that has no allowance for tolerances? Software that requires things to be exactly aligned and touching to work?

An example:

Walls are defined by the layers of materials that they are constructed from; e. g. plasterboard / stud / plasterboard. The thickness of these are set by the manufacturer's nominal thickness. In this example 13 / 92 / 13 = 118mm. But will this wall be exactly 118mm, everywhere, when measured on site?
Now say you have an escape corridor that has to be no less than 1200mm wide, with 118mm walls on either side. How do you ensure 1200mm is the dimension the building inspector measures after it has been built? You need to make a decision about where it is set out from (an intentionality issue - see above) and where construction tolerances are taken up. The question is how do you do this in a pure BIM model?

A common workaround is to add tolerance to material thickness, so 13mm plasterboard become 15mm. Problem with this is the estimator may cost 15mm plasterboard instead of 13mm, or worse the contractor orders 15mm plasterboard.
Another workaround is to model tolerances. For example add a 'tolerance' material 2mm thick to either side in the above example. The problem with this approach is you see things that are modelled. But tolerance is not something that gets built, it is an allowance that get absorbed when the design becomes real (like collapse of a quantum wavefunction). So it can get confusing for people when tolerances are modelled.

Like intentionality there are many ways this issue could be dealt with. But first it needs to be recognised a problem that requires a solution, something I have yet to see.


During the design phase there are many questions and unknowns floating around. Rather than everyone keeping separate lists placing these directly in the BIM model ensures they are available to all participants, in something you know they are going to look at.
What I like about comments in the model is the issues they point out remain in everyone's face until resolved. And in any case if in a proper BIM model they can be scheduled to create lists for those who like lists.

The problem of comments is similar to that of intentionally discussed above. The difference is intentionality is part of final deliverables, comments are part of the process of creating deliverables, but not a deliverable themselves. Nevertheless the solution to both may be similar.

Whilst it is true that elements can have comment parameters, comments do not necessary relate to individual elements. They may relate to multiple elements, elements missing, ("window required here?") or general comments not relating to any particular elements, ("redesign this area").

I find it surprising BIM software doesn't have this ability, or that people are asking for it, as it is common in lots of other softwares.

Once again there are workarounds, but they are usually annotation based rather than embedded in the BIM model. In Revit I use an annotation symbol with parameters that can be scheduled, but of course these are only visible on drawings, not really a BIM solution.


It is a normal requirement to identify changes between document issues. The method to do it on drawings is well established. But there doesn't seem to be an established method for BIM.

The method drawings use is not really suited to BIM.  It is not possible to manually flag a revision in the model. A change in the model may effect many drawings, each has to be tracked down manually to have a 'cloud' added. Revisions are added after the fact, whereas the act of making a change could in theory automatically flag a revision.

I have to admit I find the traditional method of managing revisions painfully time consuming, hard to enforce, and often uninformative (how many times have you seen "General changes").
But whenever I have suggested alternative methods that are more efficient and informative it fails to be implemented because it is not "the way revisions are done".

Other softwares keep 'histories' that could generate revisions, so it is technically feasible. (Andreas Ricke of AR Software Solutions has a Revit add-in that can track changes).

But what is missing is an agreed workflow or method that communicates changes. A few off the top of my head: Colour coding elements changed since last issue, automatic attachment of links to changed elements (like hypermodelling).

I'm not sure why a better method for managing revisions hasn't surfaced. Maybe it is a chicken and egg situation. The software houses are waiting for some agreed method from the industry, industry can't explore alternatives because the software can't do what they need.


To me these are the four big things BIM doesn't do that are holding back BIM from being a deliverable for construction in its own right.

I don't believe any are insurmountable. Although they will ultimately rely on software functionality, they require agreed workflows. Something that should come from the AEC industry. We shouldn't just wait for the software houses to make something up they think they can market.

Anyone have suggestions about where we start?