29 August 2015

Everyday BIM

This month 3 years ago, August 2012, I started the practicalBIM blog.
My original intention was to blog about practical ways to make BIM work. But when I started reviewing the literature on BIM I became alarmed at the misunderstandings and direction BIM was heading. It soon became apparent that as well as things that should be done to make BIM work, there are also things that should NOT be done to make BIM work (or at least not more work than it needs to be).

It seems to me the misuse of BIM stems from some basic conceptual misunderstandings, (or intentional misconstructions) of BIM. If I believe these people are mistaken, what is my conception of BIM? How and why is it different?
So on this anniversary I thought it timely to do a post setting out my views on BIM; not special, world changing BIM, just ordinary Everyday BIM.

First some thoughts on what BIM is not.

BIM is not  A UTOPIA

BIM is a set of processes that manages certain technologies. It is, and always will be, changing. As new technologies become possible new process will evolve. And it will eventually be superseded by a new acronym for a different approach, just as BIM superseded CAD.
There is no end, no point in the future where BIM will be perfected and stabilized.

Why is this important to appreciate? If you are adopting BIM under the assumption it is a one off exercise that leads to an amazing outcome you will be sorely disappointed. If you are waiting for BIM to reach perfection before adopting it you will be waiting forever.
There will be improvements, but the perfection promised will never arrive, and the need for further changes will not evaporate.
BIM is not an end in itself. It is a process of continuing improvement.


There is a myth a particular type of contractual arrangement is required for BIM to work, so called Integrated Project Delivery. This is allied with a work arrangement being called "Project Team Integration".
There is nothing wrong with Integrated Project Delivery, its aims of shared responsibility, risk and decision making is laudable. But just as you don't need to use BIM to achieve these aims (e.g. The National Museum of Australia used CAD), using BIM doesn't require IPD.

The insistence that the construction industry must move to IPD type contracts and work arrangements for BIM is a naked attempt to use BIM as a driver to improve the way the way the industry works. This is great for bettering the AECO industry but detrimental to BIM adoption. BIM is not the only, and certainly not the most critical, driver in the selection of contractual arrangements. Making the assumption IPD is necessary for BIM leads to BIM not being considered for projects that require other contractual arrangements for reasons other than BIM.


There is an underlying assumption that a BIM model must become a single unified 'thing' ("Integrated Data Environment"), and that all BIM processes must be under the control of one entity.
This view is promoted by the UK Levels of BIM Maturity (as per the Bew Richards diagram), where 'Level 3' BIM is an integrated web based solution (so called 'iBIM').

The only realistic way this can happen is if all participants use the same platform, or all rigorously comply to the same Standards, (assuming multiple platforms will be able to communicate via data that adheres to Standards).

Whilst it is true greater efficiencies are theoretically possible by tight integration of all aspects of design, construction and operation, there are consequences of this approach that are being ignored.

Forcing all participants use the same platform will lead to inefficiencies amongst individual parties. Each of us make choices about technologies and processes that are the most efficient at fulfilling our responsibilities. And because of competition the best available comes into common use. These individual actions add up to an efficient and cost effective overall process. Any 'all in one' platform will never contain the best in breed across all disciplines.
The result of  this approach will be the dominance of proprietary software monopolies, a situation all the software houses are currently scrambling to take advantage of.

The requirement for such tight integration will also encourage the ascendancy of large multi-disciplinary firms and vertical integration into AECO conglomerates. Say good-bye to the bespoke architectural design firm, medium size contractors and specialist sub-contractors.

The expectation that iBIM will be possible through the use of Standards is just a fantasy, more on that below.

The whole idea of iBIM is analogous to a command economy. In theory a fully managed economy with centralized decision making should be more efficient. But in practice a market where individuals make the decisions is more efficient. Blatantly demonstrated when the USSR collapsed, and more recently the problems in Venezuela.

BIM is a set of processes that manages certain technologies. There is no reason those processes can not be tailored to suit ways of working that maintain the efficiencies of a market approach.

That is not to say iBIM is not a realistic prospect, nor that it will never happen. The problem is when it is assumed it will be the ONLY future for effective BIM.


There is an enormous expectation that Standards will make BIM not just more efficient, but in the minds of many BIM will not be truly possible until Standards are in universal use.

Now, I believe Standards are a good thing, which is why I follow their development so closely. But they are not the panacea they are portrayed to be. And the main reasons are inherent in how Standards are created.

Standards take a long time to be developed and agreed. Most work on Standards around the world is done for free by volunteers. The process for approving Standards is also unpaid and requires many people, often from widely dispersed places, to come together. This is particularly pertinent for technology dependent processes like BIM where Standards trail current practice not by years but by decades.
Because Standard creation and agreement is largely unrewarded the best and brightest, most experienced, are not attracted to participate. Although it does tends to attract academics, where their participation does bring reputational rewards. They may be the brightest, but lack practical experience and tend to create obtuse documents no-one else but fellow academics can comprehend.

So Standards invariably document out of date practices in a manner that can not be understood by those who are supposed to follow them.

I don't see how it will ever be possible to entirely rely on Standards and their adherence to deliver BIM. Processes and conventions developed by individual people, firms and project teams will always pay a major role in BIM. Just as proprietary software and formats will always be at the forefront of BIM technology.
Standards development should focus on supporting market driven BIM, not be put forward as BIM itself.


BIM is often portrayed as a process where some-one will provide some-one else with a product that reduces that persons work. For example a facilities manager who receives a BIM model will gain a record of the constructed building that can be used to manage it.

Whilst this is broadly true, this is interpreted to mean that the provider will do the work of the receiver. That if the facilities manager can't directly use the BIM model, use BIM data to populate their FM database, the provider has not done their job properly.
This is propagated by the myth that a BIM model can be used for any purpose, even if created for a specific purpose. An architect creates a BIM model to communicate what is to be constructed, not to manage a built facility (in any case they wouldn't know how to - architects are not facility managers).
And if a BIM model can be used for any purpose, there is no requirement to pay some-one to make it fit for particular purpose. So there is an expectation this work being done on the receiver's behalf is free.

I can see no justification for this belief, yet is surprisingly common among owners. It is often a roadblock to BIM adoption. An owner wants BIM, but doesn't expect to pay for it. When a cost is put on it by the AECO participants BIM gets dropped in its entirety. The project becomes a 'non-BIM' project and BIM is actively discouraged.

So what is BIM?


At its core BIM is a concept - the idea that the physical building, systems within it and processes used to realize it are modelled before a building is built.
This sounds simple but is a paradigm shift from how most architects and engineers view their deliverables. The norm is to privilege drawings - that the firm's output are drawings. Of course their real output, and what everyone else expects, is information. Drawings merely communicate this information, they are nothing more than a tool.
When training CAD users to use BIM software the biggest hurdle is to get them to understand that the drawing is not the most important aspect. To get them to stop obsessing over line weights and concentrate on ensuring wall definitions reflect what the wall is to be constructed from.

Once people get it - that their job is to model, not to draw, everything becomes much easier.
And if you don't understand this, you will never use BIM to its full potential.


The degree BIM is possible is dependent on available technologies - software and hardware. When I first started using AutoCAD in the 1980's I got excited when I saw you could use layer names to describe what elements represented. Back then that was all we had available, but it was still a form of BIM.

It is often said that BIM is process, not software. Whilst this is true BIM is process that manages softwares. Therefore BIM processes are limited to what software can do.
It is pointless developing BIM processes and Standards that are independent of available technology. Pointless because no-one can use actually them, or are forced to invent elaborate and time consuming workarounds that mimic those impractical processes.

BIM is in practical terms technology. Ignore this fact and you will soon paint yourself into a corner.


BIM is a set of processes that manages AECO technologies. Individual processes that can be linked to and linked from other processes. Processes that work in parallel, branch off and have different outcomes, a bit like they way a molecule is structured. BIM is not one single linear process that will only work if all parts are in use.
Any part of the design, construction or operations of a building can use BIM. It doesn't have to be used all the time for every task.
While it is true some processes aren't possible if other processes are not being used, it does not necessarily follow that one process justifies the implementation of all its precursor processes.
Nor is the fact a particular BIM process is not being used reason enough to not use other BIM processes.

BIM entails multiple processes, each of which should be justifiable for its own sake.


The original intent of BIM was that by capturing work in a digital format it would be more useful to those that utilized the results of that work.
It was never intended to mean that BIM is a new, additional task that produces the raw data required by others to do their work. That BIM data provided will be structured to suit the work processes of others.

The workflow envisage was that some-one provided their BIM model to some-one else, who then extracted and restructured the information they required. The provider remains responsible for their data - that it represents their area of expertise and deliverables, but they are not accountable for its use by others for purposes outside of their responsibilities.

A services engineer provides a BIM model of ductwork to the contractor, which the contractor may use to create fabrication BIM. If there is an error in the fabrication model it is not the services engineer's responsibility, but if there is an error in the capacity sizing provided it is. If architects model a building in 3D, and the structural and services engineers do the same, then this provides sufficient information to use software to check for clashes.
Providing someone with BIM data gives that person the opportunity to use it for their purposes. It may require validation and adjustment, but it is still usable and useful.

What BIM does is provide an opportunity for improved efficiency and quality of outcome through the availability of data. And this is best done  through fostering cooperation and collaboration, not rigid demands, especially from those outside the immediate process. 


How might this approach be used everyday for real projects in the real world?
Some general suggestions:


Restrict BIM demands to things you need directly (e.g. asset management), and to ensure general BIM proficiency (e.g within discipline expectations like drawing and schedules generated from BIM).
Don't make BIM data a deliverable if you don't need it yourself, instead include engagement contract clauses that allow for the exchange of data between project participants.


Use BIM capable software in the way it is designed to be used.
Document how you structure your data and make both the description and data available to others.


Take advantage of the BIM data available on a project.
Foster BIM processes, along with cooperation and collaboration across project participants.


Embody BIM processes in supply chain and work management. Tailor those processes to take advantage of available BIM data.
Allow others to use the data you produce.


Develop FM solutions that take advantage of available BIM data.
Become involved before facility handover so you can make your requirements known to others.

Notice I haven't mentioned Standards. That is not because Standards are never useful or don't have a place. It is because Standards should only be used if they are beneficial; if they assist in achieving the underlying aims. The decision to use Standards has to come from project participants, the ones who create and use BIM data, the only ones who can assess their usefulness.

I hope you find these general suggestions helpful, even if they are perhaps too brief to be truly practical, something I will aim to ameliorate in future posts.