BIM is No Integration Proxy

Posted on July 4, 2010


While watching the World Cup soccer finals, it is easy to see why one player fouls another:  to make up for a weakness. Compared to the superior player, the offending player is either fatigued, strategically outmaneuvered, lacks speed, or is simply not as skilled.

Project teams with little or no experience in the finely-tuned integration machine required for Integrated Project Delivery attempt to cover their weaknesses up in several ways. One of those ways you may hear is “We’re integrated:  we use BIM.”

Building Information Modeling is a tool. Integration is a process. They both take time to gain proficiency, but mastery of one does not lead to mastery in the other. It is a logical fallacy, post hoc ergo propter hoc, to believe proficiency in A causes B.

Integrated teams may use BIM, but BIM is not required for well-executed integration. Integration at our company happened long before BIM came along.

As a company passionate about integration, Haskell does simple things to achieve it. We employ architects, engineers and contractors; it just makes sense for everyone needed on a project to work for the same boss. We sit those architects, engineers and contractors together so they communicate as a team more frequently than they would otherwise. And we coordinate decisions, even small ones, to avoid RFIs and items that might accidentally increase project cost.

BIM is a tool in the IPD toolbox, and an important one at that, but it takes a lot more than one tool to achieve integration and master Integrated Project Delivery.

Covering up weakness is an old trick. From casual conversation with prospects to the short list interview, teams employ smoke-and-mirrors to cover weaknesses. It is the owner’s job to look for them and call “foul!”