How many times have you been told that an IT project is “just like building a house?” I swore that if I ever heard anyone use that simpleton analogy again I’d leap out of my chair and throttle the twit.
I was wrong — not that that’s unusual. As I write this column, my wife and I are preparing to take possession of a new house that’s been under construction for four months. As we get ready to sign off on the final product, it occurs to me how very much like a well-run IT project this has been.
The builder was very careful with the specs, and backed them up with blueprints, just like we’d back up a programming spec with screen shots.
After a thorough review of the specs, we negotiated a fixed price and a move-in date with the builder, and we both signed on the bottom line. A price, a date, specs and blueprints — we now had a solid project baseline, and a good understanding of all three corners (cost, duration, and scope) of the PM triangle for this project. All the criteria for success were defined before we got started — almost enough to bring tears to my eyes.
Of course we couldn’t get through the project without at least a couple of change orders. This guy was a master. Changes? The answer was never “No,” and neither was it simply “Sure, we can do that.” The answer was, in fact, always “We can do that, if you’re willing to accept the implications that come along with that change.”
An example: “I’d be glad to change the location of that door — the standard price for moving a door like that is $XXX (corner one: cost), and it’ll delay your move-in date by one week (corner two: duration). I thought he’d missed one corner until he said, “Oh, and it will also mean that we have to delete that front-entry lighting fixture to accommodate the change” (corner three: scope). “Before we do anything,” he said, “we’ll get your signature on a change order and make sure we both have a copy for our files.”
This guy could’ve been the poster boy for the Project Management Institute.
Now I’m sure that we’ll find a couple of things in the house that we’re not satisfied with. As long as I don’t ask for something outside of the spec, I’m confident that my diligent builder, incented by my 10 per cent fee holdback (I didn’t just fall off a turnip truck myself, you know) will find it in his best interest to finish these last details to the spec in short order.
As the project sponsor, I saw the value in paying close attention to what was going on at the site on a nearly daily basis (OK, I didn’t, but my wife did). Minor mistakes were discovered quickly, and rectified just as fast — who said user acceptance testing only starts when all the coding is done?
This guy is good, but he’s not a god, and neither is anyone I know who manages IT projects. He started some things too late, and I wasn’t surprised to find out there was a mad panic on the site for the last two days to get everything done on time. Anybody who’s ever crammed at school knows what I’m talking about, and so does every IT person who’s ever pushed to wrap up a project on time.
This experience also underlined for me the value (not the cost, the value) of an excellent project manager — they’re even harder to find in IT than they are in construction. I’m reminded that the best in IT are never the “accidental project managers” who kept getting promoted through technical jobs until someone stuck the title “Project Manager” on their cards. And they’re rarely, if ever, someone who was the best technical person in the IT shop.
To stretch the analogy a little further, would you trust your IT project managers to build the house your family was going to live in? If not, why not, and what are you going to do about it?
And to the last IT guy I heard using the house analogy for his project…I was wrong, and I apologize sincerely for the severity of the wedgie.
Hanley is an IS professional living in Calgary. He can be reached at [email protected].
