Talk or Die

My girlfriend owns a 2000 Toyota Corolla named Sally. Sally spent the first half of her life on the East Coast, meaning that she is quite rusted and corroded due to road salt and water (two things that California lacks in any significant quantity).

Like many Toyotas, Sally has a slow oil leak.

Like many boyfriends, car maintenance is one of my contributions to the relationship. 

My strategy with the oil leak is to keep a five liter jug of oil in Sally's trunk and to top her off almost as frequently as we top her off with gas. If we go too long without filling up Sally's oil, she starts running pretty rough. If we let her go long enough without an oil fill-up, her engine will seize up and turn into a rock. We would have to spend a ton of money to get her running again.

BIM projects behave exactly the same way as Sally. The BIM project is Sally the car, and talking is the 5W-30 motor oil I keep pouring into Sally. You can start a project without any talking, but it's not going to get far, it's going to be rough from the get-go, and it'll soon turn into a disaster that will be massively expensive to fix.

The thing about BIM isn't so much that it's complex, although it is. It's that it isn't obvious. The consequence of this non-obvious complexity is that it is not a given how any thing should be done, because there are multiple legitimate ways of doing it. 

The best way to deal with this complexity of the BIM process is to talk. To talk early and to talk often. With as many people as you can. And by "talk" I mean "have conversations, ask questions, and listen", don't just yammer on about your pet process map*. 

Of course, at some point, you have to shut up and get some work done. Knowing how much talk is appropriate will only come with the experience of a few projects. Just keep this in mind: the consequence of talking too much is that you will annoy some people and waste some time. The consequence of talking too little is a massive pile of burning money, figuratively speaking. 

A pitfall that is easy to fall into is assuming that BIM is just the new, fancy, updated version of CAD. This is wrong. BIM is not CAD 2.0. BIM is not CAD except with a few extra features. 

BIM is a fundamentally different activity than what we've been doing, ever.

It requires different skill sets, mental models, processes, and language, and it is entirely different in scope. The rules that applied to CAD projects do not generally apply to BIM projects. CAD projects were relatively straightforward to set up, at least by the mid 2000's. There was a certain amount of communication required but in general everyone "got it".

No one "gets" BIM. We all have no idea what each other are doing. I have no way of knowing what coordinate system an architect is going to use, or if they're going use to use Worksets like Phases and Phases like Design Options. We need to discuss if we need to build the models to Facilities Maintenance standards or not. We need to talk about who is going to model the light fixtures, and when. And on and on. If we don't talk about these things, each team member is going to be running around in circles trying to figure out how the project is set up and how to simply get the model to a point that they can start getting actual work done.

This situation of needing to do a lot of talking at the beginning of every project is due to two reasons. First, like I said, BIM logistics are just really complex in a non-obvious way. Second, we're all pretty new to this. BIM is not a mature or stable technology yet, and we're all still figuring things out as we go along. 

I can certainly imagine that in another few years, the industry will mature to a point where most aspects of BIM project execution have settled out into standard workflows and methods that everyone is comfortable with, but we're not all there yet. Particularly for firms that are new to BIM, or are still developing their BIM proficiency, the communication imperative is the number one make-or-break factor in project execution.

In the next post I'll get into some of the specifics of actually how to effectively communicate on a BIM project, as well as identify the most important phase of a project. 

*Full disclosure, I'm a huge fan of process maps, and have an extensive archive of process maps I've created. Most of them are awful, which is why they're in my archive, but the process of mapping out the process is what was most valuable. Which is a bit meta.