Commitees Suck for Deploying Software

I know the drill.  Hey look!  New software!  Let’s set up a committee!  Let’s get everyone’s input!  Let’s hold hands and sing folk songs and this software will magically deploy itself when butterflies flit around and run the installation files on everyone’s PC.

No no no.

As architects, we like design charettes.  We like to get together and hash out unique solutions to design issues.  That’s great.  You can come up with excellent resolutions to some big problems.  And quite often, that’s close to the most social some of us ever get.

That shared workforces mentality can spill over into other facets of our business.  Let me tell you, deploying software isn’t designing a building.

Aside from the charette mentality, to maintain good relationships in a firm, we like to make sure everyone feels like their opinion has been heard and counts.

Deploying software isn’t like ordering pizza, either.

I’ve been through a couple major software deployments now, and each time, the committee gets used less and less.  Why?

Because committees suck for deploying software.

Now, I’m not talking the lone wolf here.  I don’t endorse the idea that one person should be making all these decisions.  Sometimes that works, with Revit, it won’t.  But a committee is the wrong approach.  Get three people, each more opinionated than the next.  That’s your core group of decision makers for a Revit migration.

Why is a smaller group better?

Standards changes– I said in an earlier post that I was using our Revit deployment as a jumping off point for enforcing our standards fresh.  That does not mean that we used Revit as a reason to rewrite our entire standards book.  On the contrary, we used our old standards as a jumping off point.  We were going to be making enough changes with just the software without having to change everything.  Often, our hand would be forced to look at and change the standard because of how Revit functions (leaders at the end of text, I’m looking at you).  Usually the smaller team would be quickly in agreement.  A large committee would require way too much time on conversation and evaluation of the issue.

Education – Some issues are new and hard to understand.  It’s far easier to train three people on a complicated issue to make a good decision than it is to educate a roomful.

Passionate ideas – sometimes an individual in the smaller group would be VERY passionate about an issue.  The others would give way, understanding that their pet issue might come up soon and there would be some mutual back scratching.  With a larger group, there is a lot more heel digging in, just to dig in heels and feel like you have to be forceful on each issue so you’re heard.

You might be right – in some situations, you’re just right.  It doesn’t matter what others say, you know you’re right.  Convincing only two people is a lot easier than a roomful.

You might be wrong – in some situations, you’re just wrong.  You think you’re right, but you’re not.  It’s much easier to get shown the error of your ways by a small personal group than by a large room of people.

Camaraderie– a small group makes it easier to feel like a team.  By the nature of being in your group you will get each other’s back, because it’s just the three of you.  The larger groups can easily break down into smaller factions and then you just have group A arguing with group B, sometimes outside of the meeting and that is just plain bad.

Try to avoid the committee for your Revit deployment.  Find one or two competent and appropriate individuals to work through this important task with.  It will go much faster with a smaller group.

And, if someone complains, you change it.  But in my experience, the amount of complaints and changes to newly deployed software has no correlation to the size of your deployment team.

Media Control During Your Revit Deployment

Several years back, I went through a Microstation (with PArch – yeah to the Intergraphers in the house!) to ADT migration.  I would absolutely categorize major portions of it as a disaster.  At least looking back on it I would call it a disaster.  I was able to build on that experience to coordinate and control our ADT to Revit migration.

The migration is still technically going on, but we are nearing the end of the big push.  I feel confident that this time around things went a lot better, which in some ways is odd since hopping from Microstation to ADT is nothing compared to the hop from ADT to Revit.  For the most part, the first transition was “OK, instead of clicking this button, you click this button, and oh, yeah, you can have infinite layers and you have to save all the time.”  Huh.  When I put it like that I’m sad that I screwed it up so badly.  Anyway, the ADT to Revit transition is more like “OK, instead of clicking this button you need to completely change how you think about putting a job together.”

Wow, I really got lost in that one.

Anyway, one of my tactics for the Revit transition was to control everything that was put out to our firm’s general users about BIM and the software.  If it was about Revit, it was 1984 and I was Big Brother.  There were a couple slips at the beginning, but once I explained to my bosses what needed to be done, a filter was set up where any media, any meetings, any discussions any anything that involved BIM or Revit was put through a filter in our firm.  That filter was me.  I never before invited myself to meetings, but I started to.  Sometimes there were just donuts and the meeting had nothing to do with Revit, but that’s another story…

If you are working on your deplyment, if you are partway through your transition, it is not too late to make this important step.  It might not be you, but someone has to be seen as the BIM Master in your firm.  Not a committee.  You can’t have a hydra BIM Master.  I mean, there has to be a committe to help migrate standards, but there has to be a single face of BIM carrying the flag and mixing the Kool-Aid.

This might seem extreme and archaic, but it is so much easier to maintain control later on down when the deployment really ramps up.  I’ll be sure to take some time later to post some other thoughts on a successful deployment including how to be sneaky and why commitees suck.

It’s March Already! Plus Some Minor DWF Thoughts

So, it’s the beginning of a new month, and those of you playing along will know that that means it’s time for some Revit training at my firm!

This three day crash course finds me on the road to our Virginia Beach office.  I’m blogging from a hotel room.  The schools back home are still closed thanks to the weather, and frankly, it’s REALLY cold down here.

This office’s primary job type is higher education, so that’s nice to get some input on new techniques and practices that we need to bring into the fold of our standards and possibly incorporate into the template.

I’ve found that this Revit deployment has been a good time to do some more standards pushing firm-wide.  No matter how much you try to create and maintain standards with AutoCrap, it always seemed impractical to maintain the level of staff that would be necessary to verify and enforce those standards.  With Revit being so fresh and new to a lot of these folks, we are only teaching them what they need to know to get their job done, and that is always standards specific.

On the flip side, this is forcing us in some cases to reevaluate our standards.  We’ve redesigned our border, amended how we use keynotes, and some other items have gotten the boot or the overhaul.  The funnest part is when everyone thought there was a standard, but it turned out there were about 27 different ways that PMs were doing the same thing (mortar joints in wall sections – I’m looking at you).  It is definitely a task that won’t be done anytime soon, but it is easier to begin the task with Revit.

I’m also using the push as an excuse to endorse greater adoption of DWF use in the firm.  I have never been 100% happy with PDFs and how they handle large format drawings.  I’m always slightly nervous that something is messed up.  So far, DWFs have not let me down.  With each training, I discuss exporting to DWFs and show the markup features and how that can integrate back into Revit sheets.  Really nice stuff.  We’re close to getting some more of our QC guys to work along with us on the DWF front as well.  Really excited about that.

Money Talk

This popped up on Google Alert this morning…

http://seekingalpha.com/article/123193-autodesk-inc-f4q09-qtr-end-01-31-09-earnings-call-transcript?page=1

It’s a transcript of an Autodesk conference call concerning their fourth quarter money stuff.  It’s long, and for some folks (like my dad) it would be interesting.  I bet I would find it interesting if I could understand it, but frankly, my brain isn’t wired for this sort of thing.

They didn’t hit many specifics, but considering this is a Revit blog, here are some highlights that I will comment on:

• Revenue was down (duh) – it didn’t feel like it was down any more than anyone else this past quarter, though.
• Revenue from ACAD and ACAD LT was down 21%
• They didn’t mention ADT or ABS directly – they did mention a 14% drop in their AEC “segment”
• Revenue from Revit products was only down 6%

My gut tells me that in the current economic conditions, a 6% drop in revenue is not bad at all.  That tells me that the revit adoption rate is still moving along at a nice clip.  I know attendance in our local user group has stayed nice and consistent through the last few months.  Some folks have lost their jobs, but I think they understand that now more than ever, they need to invest in themselves for the future.  In our industry, that means learning and understanding Revit.

My concern now is that Autodesk will be more concerned about making cash over getting Revit out there into the masses.  We are migrating licenses from ACAD products to Revit products as we deem it appropriate.  I am worried that Autodesk won’t be willing to cut us some deals on these transfers.

My biggest concern is that they will up the cost of subscription.  On principal, I like subscription.  However, in its current state I have a hard time internally justifying the cost.  There aren’t that many benefits.  I would love to see some kind of cost adjustment on new seats based on the number of current seats we have under subscription.  The annual updates are nice, and we update each year on Revit, but some years the reasons are less compelling than others (cough-cough-ribbon-cough-cough).

So, if you have an accountant’s brain, read through the link above and see what you think.

Sketchup Users – The Steep Learning Curve

Change is hard.  I totally understand that.

Sketchup is easy to start using.  Check.

Revit isn’t easy to master.  I get that, too.

Now that we have the baseline set, we can start.

In a previous post, I talked about how evil Sketchup is to the documentation process, and ultimately a disconnect that it creates can impact the design process as well.  As we are moving past our pilot projects, we are introducing the concept of BIM and Revit to the population of the firm at large.  Some of the folks are 100% on board with the concept.  They know there are going to be hiccups and a rough time learning the software, but they are ready to get their hands dirty and come along for the ride.

Now (and here’s where things took me for a loop) on the other side, I have the Sketchup lovers.  They are not ready to move along.  The extreme cases find folks who find multiple excuses to convince themselves that modelling in Revit is bad and completely subpar compared to Sketchup.  Don’t worry about the built-in rendering engine in Revit.  Ignore the fact that you have started your documentation.  Pay no attention to your engineers who can start their analysis based on the Revit model.  You can’t do any of these with vanilla Sketchup.  You can start tacking on add-ons, but they are iffy, thrown together and sometimes expensive.  On the other hand, this is precisely what Revit is made for.

I mentioned that the Sketchup hold-outs threw me for a loop.  I had convinced myself that the 20 year ACAD experts would be my biggest fight.  That hasn’t been the case at all.  In most situations, while they lament losing some key features and functions, they have been on board and are quite excited about making the change.  As one of them put it, “This is what computers should have been doing for the last 10 years.”

So, what to do about our Sketchup folks?

Right now, there isn’t much I’m doing.  I am putting my time and energy into the people who “get it”.  I am whole-heartedly convinced that once the learning curve is crossed, the models created in Revit will be superior in so many ways to the ones in Sketchup.  And the projects will be better coordinated.  And the rainbows and unicorns will return to the golden fields and it will rain chocolate!

Seriously, there isn’t much I can do.  I can’t twist these people’s arms.  That would accomplish nothing.  I am getting the people who are along for the ride better training and support.  We are working hard to prove all these theories.  And then I am hoping peer pressure will do the job of converting the die hards for me.  They need to be willing to take the time to learn the tools, and I cannot push people into willingness.

If that doesn’t work, I get out my BIM Stick.

Why I Hate Sketchup

One of our biggest fights with our Revit deployment has got to be with the die hard Sketchup users.

I absolutely understand that Sketchup is easy and doing Revit properly is… not as easy. I get that, I totally do. And the really good Sketchup users, when they finish a model, everyone oohs and ahhs, because it looks so good and it’s so amazing. Then why is Sketchup a bad thing?

If you are reading this, you know part of the answer already.

Sketchup is 100% outside of the documentation process for most firms. Sketchup Master has spent all this time creating this elaborate beautiful model in Sketchup. Now let’s waste some time rebuilding the entire thing in Revit so we can actually put out a set of construction document, which is ultimately what we do. I find it interesting how, on a macro level, this issue with Sketchup reflects exactly the same issue that BIM as a whole process is trying to work past. In the “rainbows and unicorns” world of BIM, the passing of the model from designer to contractor to owner is an attempt to not lose valuable knowledge and information that has been put into that model through the process. The Sketchup to Revit shift is the exact same loss of information. It is a waste of time that is unnecessary.

I would submit another reason Skethchup is bad, bordering on evil. It is imaginary. Now, before you start yelling, I know you can make Revit do some pretty amazingly fake things. Things that completely defy the laws of physics and gravity. But if you use the tool correctly, Revit has checks in there to try to help you along the way and not design something that defies the laws of time and space. Sketchup is nothing but fantasy design. Hopefully the designer has enough experience and knowledge to be able to avoid the pitfalls of building a completely imaginary model, but this isn’t always the case. Sketchup makes it very easy to design something that simply cannot be built. And the owner loves it and it’s gonna be on the cover of some grand architectural review magazine! Except that it’s entirely fiction, and when you Revit guy starts duplicating the model in Revit (which is a waste of time – see above) he or she finds this discrepancy with reality and has to spend more time discussing a solution with the Sketchup designer to find a solution.

Sketchup has a place. That place is the first five minutes of predesign, schematic design or whatever you might want to call it. That’s it. The word “sketch” is in the name for a reason.

This is one of my big soapbox items. I could rant for much longer, but frankly this blog post has gotten too long. I will post again soon where I discuss what I have found with some Sketchup snobs users and how we are trying to deal with them.

Walls Have Tops Too

We have settled on never ever ever leaving the top constraint for walls to be “unconnected”.  Even if they are short, like partitions for cubicles or something, we still connect them to the level they are on and then offset them to the proper height.  Why would I be such a wall top constraint fascist?

Engineers.

Isn’t it always that way?

Seriously, they need the tops of the walls to be constrained to something.  For most of the walls.  So, it’s just plain good habit to get into to always pay attention to the tops of the walls.  Or the top of everything for that matter.  Remember, this isn’t CADD anymore.

“Model it right and your documents will follow.”  I think I read that on a fortune cookie once.

Contractor’s POV – Part 2

So, we had the talk from Harry McKinney of Clancy & Theys last week and I promised a follow-up, um, write-up.  And this is it!

The talk was great.  Harry did an excellent job of pointing out some specifics about how contractors are starting to use BIM and Revit and touched a little on how they are trying to work with designers to get the single model approach. 

One example would be the sandwich wall.  For simplicity and ease, the architect will typcially just create a wall type with all the materials sandwiched together – brick, air gap, insulation, CMU, etc.  Harry told us that they often will create individual wall types that line up together.  One reason is that they are using BIM for staging and construciton timelines and the different wall types let them simulate the construction cycle more accurately.  The other reason is more control over cost estimating.

I am not going to go recommend to my architects that they start breaking all their walls up to place as individual walls, that would be a waste of our time.  But if we have a design-build project, it is certainly something we will need to consider.

Or maybe Autodesk can build in a nice function that will break up a wall to its core components as separate walls, kind of like you can break up a stacked wall to its subwalls.

Anyway, Harry was very well informed and more importantly very excited about the topic.  I’d like to thank him for his time coming out and sharing his knowledge with us.

Rooms Are In Section – What About View Range?

So, Revit 2009 introduced the wonders of seeing rooms in sections.  Hooray!  That was terribly exciting for a couple minutes.  Now it’s time for something practical.

One item that would be so much easier to control graphically are view ranges.  All plans and RCPs have them.  You can control elevation “ranges” in a plan, why not give us some nice interface to control a plan’s view range in section?

Something like that?  A toggle at the top and bottom for UNLIMITED on TOP and VIEW DEPTH, or a draggable bar, and a draggable bar for the CUT PLANE and the BOTTOM.  How cool would that be?

Strange Observations

I find myself looking at anything in the Real World now and trying to figure out how to model it in good ole’ Revit. I imagine that it is some mental affliction with a complicated name.
“Solid-void perception integration disorder” us what I’ll call it. SVPID for short.