Change control in the enterprise

Recently I have been reading Code Complete by Stephen McConnell. It is a very big book with over 900 pages and a ton of useful information. Many IT organisations could do a lot worse than to base significant parts of their strategy around this book. However there is one paragraph in the “Handling Requirements Changes During Construction” that did read strange to me and I would to explain my thoughts on this using the same analogy presented in this section.

If you’re driving from Chicago to Los Angeles, is it a waste of time to stop and look at a road map when you see signs for New York? No. If you’re not heading in the right direction, stop and check your course.

It is hard to disagree with this. If you’re doing quick prototypes, you can temporarily postpone the map work until these are done and reviewing them will provide the correct direction for you. But in the middle of a big project, it is much too expensive to keep going in the same direction without knowing whether it is the right one. And when you set out on a long journey, it is very useful to know where you are going. But in the modern business world, the best destination is one that is always changing.

Consider establishing a formal change-control board to review such proposed changes. Having a built-in procedure for controlling changes makes everyone happy. You’re happy because you know that you’ll have to work with changes only at specific times. Your customers are happy because they know that you have a plan for handling their input.

In my experience this just isn’t true. The customers are not happy because they are forced to fill out a lot of paperwork instead of just saying what they want. There are also unhappy because they don’t yet know if their request will be actioned or whether they’ll get something that they previously alluded to wanting but no longer desire.

Developers are not happy either. This is because developers thought that they were driving from Chicago to Los Angeles and are halfway there but now they hear that maybe they should be driving to Houston instead. At this point developers would like to know “should we take a left turn or not?”. After all there’s only so much gas left in the tank and we don’t want to be spending a lot of time and money continuing to go off course.

Unfortunately it can take a few days before the board can come to a go/no go decision on proposed changes. In those few days, developers are left in a bit of a limbo.

A strong recommendation is to try to identify work that doesn’t take you in either direction during the time of review and focus on achieving that work. But in the end either a significant amount of work that you previously did will need to be thrown away, or you’ll stick to the original course but know that you’re not really delivering what the customer wants.

This is one of the areas where Agile practices really outshine traditional sequential processes. Instead of having a plan to drive from Chicago to Los Angeles, the high level plan will be to drive west, and the initial plan will be to drive to Des Moines.

On route to your first destination you do some map work in the form of product grooming. Once you arrive at Des Moines, you’ll do plan the next iteration and decide to go to Omaha next. The regular visibility on your progress helps the customer to decide the correct direction much earlier. It he now feels Los Angeles is not the end destination, no problem make the next iteration goal to go south to Kansas City.

You’ll find that the amount of wasted work is minimized, work is delivered earlier and more frequently, and everyone’s understanding is much better. And that is what makes everyone happy!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s