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.


One thought on “Commitees Suck for Deploying Software

Comments are closed.