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?


  1. [part 1]
    Your post is interesting; I agree with your premist that the eventually, BIM will use a process of "DODO" - Drawings On Demand, Only. However, I can offer multiple examples of current, active BIM initiatives that fill in the four deficits that you describe. Allow me to address them below:

    INTENTIONALITY: I can think of a couple of BIM process initiatives here.

    First is the excellent "BIM Planning Guide" series put forward by Penn State, one of whose goals is to establish the purpose (AKA intention) for the various BIMs in a project. They don't "plug it in" to the model, but provide a very valuable conceptual framework for building owners to lay the foundation for BIM value (as in, "Remind me why we are going to this trouble, again?")

    The second is the Building Programming Information Exchange, whose purpose is to get building performance-specifications embedded in the project's Space entities at the programming stage, where they can be quantified, reviewed, and tracked over the course of the project. This initiative is being promoted by a Scandinavian software company called dRofus. I suspect that a Houston-based company, Trelligence, may also have some initiatives in this area, as, frankly does my company Vectorworks, which has an extensive set of programming / space planning tools that are integrated with our BIM product, Vectorworks Architect.


    TOLERANCE: There are not a lot of answers here, but the questions are being asked at least. Chuck Eastman, in heading up a Precast Concrete BIM standard financed by the Charle Pankow Institute, talks often about the "multiple models" required by the structural industry, and the different tolerancing required. A precast double-tee span, for instance, might multiple lengths:
    The length as drawn (in place and loaded/deflected);
    The length as formed (cambered);
    The length as tensioned/cast;


    1. [part 2]
      (Blogger prevented Robert from posting this so I've done it)

      COMMENTS: There has been a lot of work in this area. The most well-known is the so-called "BIM Collaboration Format", or BCF. BCF has been proposed as part of the National BIM Standard, version 3, which is soon coming up for a vote to be administered by the National Institute of Building Standards. BCF has some advantages over simple embedded commentary (in a proprietary BIM application) in that it allows for multiple models, of multiple origins, and stores an issue comment, a point-of-view, along with other optional attachments (such as a screenshot image.) There is really a lot going on in this space. Google "BIM Collaboration Format" to see more.

      I would also add that Vectorworks has for many years had an integrated redlining tools which allows commenting, status reports on issues, and "picking up" of redlines. They can be used in 2D or 3D and so are fully applicable to BIM models.

      As a last point of reference, isn't commenting what DWF is all about?

      REVISIONS (or what I call "Versioning"): A couple of data points here. The interesting web-based BIM server package called Assemble handles differencing of models uploaded from Revit. And more generally, the OpenBIM standards (based on the IFC data model plus some workflow capabilities) are working in this area. See:


      CONCLUSIONS: It's interesting to note that most BIM users (and most BIM software applications) pursue a drawing-centric, as opposed to model-centric, workflow. As you suggest, it will not be this way forever. However, I think that the BIM workflow will move from one of "sketch, BIM, generate drawings, build, operate" to a more generalized workflow model of what I call the "four ATEs": create, validate, fabricate, operate. CREATE is what we currently think of as the design and modeling process. VALIDATE is what we currently use drawings (and human judgement in interpreting drawings) for. This will in future give way to highly automated testing of models, which will have a profound effect on construction productivity. FABRICATE of course encompasses the procurement, fabricating and erection of buildings, which will (like the testing) become more automated and robotic. OPERATE uses the life-cycle aspects of the BIM, which are in many ways distinct from its construction aspects. I think it would be interesting to have a discussion about the difference between construction-BIM and operational-BIM and how and when the BIM model gets "branched" for this to happen.

      If you've reached this point, thanks for reading!

      Robert Anderson, VP, Nemetschek Vectorworks

    2. For those Revit users interested in the open source BCF (BIM Collaboration Format) there is a free addin for Revit.


  2. Congratulations for the post.
    I agree with everything and I also encounter the same difficulties.


  3. Dear Anthony
    I appreciate the effort to put some difficulties on the table and I join Flavia in congratulating you for it, but I disagree with the approach, and above all with the conclusion that it will rely on the software.
    Is this about "What BIM doesn't do" or "What the model doesn't do" (even without getting started with the correctness of the expression BIM model, that you used too many times for my taste)?

    Just by adding governance to the process you get answers to all the challenges. Robert Anderson's reply above is an amazing start. Just picking on TOLERANCE for example, 2D CAD is as precise - which could open a can of worms labelled "the disadvantage of precision", but in a BIM workflow you can set the clash detective to spot soft or hard clashes in the coordination across models once you add the intelligence and knowledge where needed.
    It's easy to get started in a sterile argument about software vs industry, and I imagine that this is not the spirit of the conversation you are starting, my answer to "where to start?" is simply map the process and agree what needs doing, only then pick the right tool for the task. In my experience Navisworks is a great way to track changes, communicate comments and allow for tolerances, but notice I did not rely on a name to describe the task above. Maybe the elephant in the room is constraining the image of BIM to an RVT file and not a more complex production ecosystem (despite it remains my preferred authoring tool).
    In the same line I disagree with labelling a BIM discussion with the tag Revit, or even constraining it to buildings. It was in fact brought to my attention by a specialist in BIM implementation for infrastructure, who uses a completely different set of tools but shares the same principles...
    Thanks for triggering some good discussion, online and internally in my team.
    Kind regards,

    1. William, my point is the functionality should be built in to authoring softwares.

      Of course we can get third party proprietary software to do these things. But each does it in their own unique way, they create separate workflows and are invariably after the fact - they check rather than prevent.

      I'm interested in practical application of BIM. You can't do BIM without software so it has to be part of the discussion. I apologise for my Revit bias, but it is the software I know. My intention is to use it for specific examples rather than push it as the premium BIM software.

      You are right about my terminology. I should be using VDC (Virtual Design & Construct) rather than BIM. But I want this issue to be appreciated by participants in the whole BIM process. Those involved at the end seem to have no understanding or appreciation of the VDC part. They seem to believe the model magically appears fully formed ready to be used for their specific purposes.
      Thanks for your comments.

  4. Antony again spot on. One thing on the color coding there is a non-authoring platform that does just this. It is called Assemble systems and it also offers a limited push back of information to the model. While this would be better to be in the authoring platform it does work quite nicely.

  5. I think a parallel issue is that Builders/GCs are becoming the primary stewards of the most mature, multidisciplinary BIM data -- and non-content creation tools like Navisworks have more intelligence in all 4 areas than modelling tools like Revit.

    You just need someone who can drive Navis at this near-construction phase, but also understands the design and architectural process.

    For me, this starts Monday...

  6. I like your thought that a building control officer will measure the width of an escape corridor during or once the building is completed. I've never seen a building control officer do anything other than take a casual walk around while carrying out 'chit chat'.

  7. I like your observation of the next step for bim moving from a drawing based deliverable system to a model based one. The ease of making changes in models makes many nervous. A door for example can too easily be moved or deleted by mistake. I had thought of making a validation parameter that would indicate any changes in an element and a macro that would find any element that reported a no or not valid parameter state. Revit must know everything about the model, the location and parameters of every element. The question is how to make a parameter change state for example Yes (validated) to No (not validated) every time that element changes. These changes must include changed parameters and changed locations. Once this is accomplished this parameter can be scheduled or flagged up using macros or some clever add on that can catigorize and date all changed elements. This will enable better control over changes and when a model is shared with a construction team they can be instructed to not build any element that displays a not valid parameter. Perhaps this invalid parameter can automatically send an RFI to the. Design team or be flaged up in a new revit review mode.
    In the present world this validation parameter will aid in the drawing checking process.