Google Analytics (Hidden)

Monday, February 13, 2012

What is it that we do?

Aaron Maller, that guy with the unpronouncable blog, wrote 2 posts lately about the merits of his and our profession. Basically the question was: what is it that we do?

I for one am a Building Engineer by education who kind off stumbled into the consultancy business by accident. But I do still think and work as a Building Engineer. So what is it what I do?
After contemplating a bit, which I must admit was accompanied by a fine, barely adult, whiskey, I would answer it like this:

We make believe.

That's it. We are storytellers. We take other peoples hopes and dreams and tell a story about them. We make our clients believe that they can actually come true. Off course it's up to the Contractor to actually make it happen, but hey, what's a book without the letters in it?

When you think of it: providing people with hope and making their dreams come true has always been a compelling reason for building engineers and architects. From the pharaos where the pyramids told a tale of divinity and protection by the gods, to the people rebuilding cities after they are wiped out in a war who speak of hope and resurrection. Buildings are used to tell stories of power, worship and grief.
As for me personally: my stories are far less grand than that. But stories nonetheless. I used to tell people about their new homes. How it will be build to make them happy, to last for their children and their children's children. We all have those conversations with our clients. The conversations in which we take our clients beyond their immediate needs and ask them about the distant future. Talking about how the design needs to be enhanced to suit their needs then. Those conversations have always been my favourites...

So how does BIM fit into all of this?
Back to the second post by Aaron. It's about a new highrise his company is designing and for which he is asked to convert the preliminary designs to a Revit model. While doing this the question arises what the best way would be to divide the glass curtain panels so that deformed panels are minimized, in turn providing a cheaper building without compromising design intent.
He's doing so using some high-tech panels made by Zach Krohn which have the ability to change color based on variations in geometry parameters.

Basically: whatever the topic is of your story, if you can't write properly, it's not going to happen. BIM is our pen and paper, it's our typewriter, it's our means to communicate the story we want to tell to the world.
It gives us the opportunity to review our own story from all angles, to reread what we have written, to polish and shave off the sharp edges. To rewrite our story and change it until it becomes something worth publishing.

And that's what Aaron is doing here if you ask me: working on his story. Making it better, making it more exciting to read. Using all possible recourses at hand. And that's exactly what he's supposed to do I guess: tell the best story possible.

So, as far as I'm concerned: I don't care which pen you are writing with. Just as long as you make it a story worth reading. Make your clients believe...

Friday, February 3, 2012

Sharing your model: GET OVER IT PEOPLE

Interesting discussion here at RFO today...
A member asked a question about what he/she should do with subcontractors wanting their model for QTO's... And off course the discussion quickly had two sides:

1. Because of legal mubo jumbo we can't do this AND/OR
2. The General Contractor is not using our stuff for free, and get paid for it. If he wants our model to do Clash Detection or QTO, it should pay extra.
3. Well, I am not giving up my content in which we put a lot of hours so that someone else benefits from it.


Just give them the model already...

I work as an independent consultant. Besides telling people what to do, I also get hired by firms that need an extra hand with modelling or just setting up a project. And last but not least: I implement Revit for all kinds of firms (architects, contractors, subcontractors, and so on).
And I have my own building projects, some leftovers from back in the days when I started out as a freelance building engineer. So basically, I'm all over the place.

But the one question I always get is: should we share our model. And the first response always is: HELL NO! For either one of the above reasons.

Let's start with the first one, cause that's easy:
Anyone wanting my model, be my guest. But it comes with an "as-is" waver: I did my part, you can have it to do yours. But don't hold me responsible for errors in your work when you use my model. Period, case closed. Now you can go all legal on me, but basically it's that simple.

Clash detection: cool, be my guest. Be sure to send me a copy of the NW-file and output. 2 options:
1. I didn't make any errors, so I look good.
2. I did make errors, and this saves me a lawsuit.
Either way, I win too...

Cost estimation/project scheduling: Let me know how you want to set it up and I'll build it for you. Again, wouldn't be the first time I end up teaching them how to easily convert non-ready models they receive. And in the worst case: next project, I get another phonecall since I already meet their standards.
Now the hard one, number 3:
For the last eight years, I have spent an average minimum of 10 hours a week on creating my content. That's 8x50x10 = 4000 hours. And that included A LOT of falling flat on my face, and recreating it. And again... And again. I have spent countless hours in making my library and template what it is today: far from finished...
Can you have my model? Sure, be my guest. Why don't I care about what you take from it? Well, that has a few reasons:

I mainly just assume that a structural engineer I work with doesn't need my fancy windows. And a GC's core business isn't modelling stuff, it's building it. And if either of them does rip off my model, he has one (1) or two (2!) types of windows/doors/take-your-picks of them since I do always purge out redundant types. So what?
Basically there are two options:
1. He understands how they are build, since he is on the same level (to be frank: in Holland not so likely to happen). In which case, he only knows how they work cause he built them in a similar way for his own library. And therefor has no need for them.
2. He is going to have a hell of a time reverse-engineering them and then needs to redo his own entire library to put them together in one project. That's also not likely.

Frankly: I see my entire model as one big advertisement campaign when I send it out. It's all about "looky here, I can build this kind of library and smart/extremely efficient template for you too!!! Bet you didn't know you could do that, did ya!". Wouldn't be the first time I end up consulting a firm I did my modelling tricks for, teaching them how my model was built in the first place... 

And there's another thing to be considered:
It's one thing to mimic a trick. That doesn't mean you know the software. I've seen people use my stuff (and they asked nicely). But they couldn't "use" my stuff as in create whole new things from it.
Without blowing my own horn too loud, my added value to a company would be that I understand the software better, know why it does what it does, and what will work vs what solution won't work. Call it gut feeling if you like. You cannot copy that. Period.
So yeah, in a few weeks you'll know how to use my content. But you'll not have the knowledge that supports the choices I've made. You'll not have the knowledge WHY I did what I did. Just that I did it... Works for now, until you reach a point where it doesn't work. And then you get bitten in the a$ for working with stuff you do not fully comprehend... Cause now you are going to have to go down the same road I went down the last 8 years to try and understand WHY I did what I did. You'll need to make the same stupid mistakes, assumptions gone wrong, brainwaves turning out to be nothing more then another night's sleep lost, and so on...

It is the main reason why I advocate that people should make their own content. Sure, it will suck big time. And you'll lose a lot of time . That's why it's called a learning PROCESS. But it's also invaluable to get to truly understanding your software.
If you ask me, everyone talking the talk about helping competitors, not wanting to share knowledge, and so on is still standing in the Autocad days with one leg. It's a dwg-reasoning. Cause yeah, when you gave up a dwg, you gave it all up. But that's because it was a stupid bunch of lines and hatches.

Revit content (if well built) has much more then that. It's only valuable if it co-exists with the right template, material naming, object style naming, consistent use of dozens of shared parameters, system parameters, schedules, filters, view templates, and so on. In short: it needs vision for it to work. I cannot transfer that so be my guest: take all you want... Even if it gives you a jumpstart. Try to abuse it and it will also set you back just as hard...

Let me ask you this:
How many people reading this are actually using components they got from other firms?
Why do you use them?
Do you schedule those elements? Do you do cost-estimating, clash detection, project planning or any other high-end stuff with them, or did you just get them cause it looked nice?
In general: do you feel you are using their full potential? The original owner probably has tons of view filters to make them do all kinds of whacky stuff. How about you?
Are those components now part of your library and how has it affected your library?
How many people downloaded stuff or ripped of a model, stared at the components for some time and haven't touched them since?

I'm curious... And I believe that the answers to this is going to be an eye-opener for everyone afraid of sharing their content. It is not as easy as dwg-blocks to rip off someones library.