What if you had a building construction process which resulted in something like 50% of the skyscrapers falling down at the end of the project?
What if you had a boat-building process that resulted in 50% of the boats sinking in the harbor on their maiden voyage?
What both of these examples have in common are:
a) a preference for low risk
b) an inability to change the specifications in midstream.
c) a set of success metrics that are unusually coincident with tradtional waterfall software project management methodologies.
The classic joke about the difference between software people and construction people is a client coming in halfway through the completion of their new building and saying “hey, I wanted three more floors — what will it take to do that?
In software, the specification-heavy projects keep failing at a huge rate, and yet very few people as of yet seem to get that the process itself might be to blame, in the meta sense. The idea that you can specify everything about a software project assumes three things:
a) you have near-unlimited time to produce a spec that covers EVERYTHING. Pixels, messages, timing, performance characteristics, how you handle international phone numbers, Canadian postal codes, and hyphenated names that occur when customer A, who used to be known as Shari Bixby, married and is now named Shari Bixby-Van Der Werff.
b) equally important, the client agrees to everything in the spec
c) most importantly, the client agrees to NOT CHANGE anything in the spec.
How do you add three more floors to a skyscraper that’s already 30 floors tall? You don’t. You scrap it and start over. However, the “add three floors” question comes up all the time in software development. Change this, do this, don’t do that, make that button red, that one green, and add a site map in seventeen languages. Oh, and don’t change the release date because our annual stockholder meeting is the day after we’re scheduled to go live.
It’s just crazy!
Worse, let’s say you did get a client that had (a) unlimited budget, (b) read the spec, and (c) agreed not to change the spec. Woo hoo! But then this client gets a really really really great business opportunity that could only be grabbed if they change the spec. Well, you say, that’s what Change Management is for. Negotiate the changes with the client, tell them the added cost and time, and have them sign a little form that says “I agree”. In theory this is great. It’s better than great – it’s positively libertarian. In practice it’s a nightmare. The client typically has one of the following reactions:
1) It’s easy; why should it take any longer to do “X” instead of “Y”? You’re nickel-and-diming me for simple changes.
2) I still need to make my date. Get it done anyway.
3) (worst) I still need to make my date, and even though I signed this stupid piece of paper, I’m thinking you’ll still make my date.
You have a recipe for ill-will. I would love to see a comment from someone who, when they gave their client a change order, actually had the client say “You know what, this is actually LESS COST and LESS SCHEDULE SLIP than I was willing to tolerate!” Doesn’t happen very often.
Further, a great many clients don’t even begin to assess what they can or want to do with their software until they see it in some partial state of completion. In Founders at Work, there’s an interview with Dan Bricklin, one of the creators of VisiCalc, and he said that most people couldn’t even fathom what spreadsheets were good for, until they saw it demoed, solving problems that they would like to solve.
The fastest-moving and most energetic work in project management today is done in the Agile realm, simply because — it works. Not necessarily all the practices, which vary from camp to camp, but the principles work. Assume that things will change. Prepare for it, plan for it, and adjust your daily, weekly, monthly and quarterly processes to explicitly address that concern, because it will bite you.