Why bother with change control?

Most change control processes are completely ineffectual.

Change controls are a pain and everybody knows it.  And it's not really the process that bothers me so much as the uselessness of it all.  If a CC ever actually did what it was supposed to it would be well worth the effort because performance issues and other problems would surface.  And while the CC process may get lucky enough to cross someone's desk who knows what they're doing and will stop something like that from happening, most of the time it doesn't and it's completely ineffectual.  So what are the problems with most CC processes?  Here are some ideas.

Rubber Stamping

Most RFCs (Request for Change) get rubber stamped because the people in charge of signing off on the process don't know enough about it to make the decision.  And ultimately they know this so they end up just rubber stamping it.  There's not much you can do about that though.  You can't teach a manager 15yrs of SQL on the spot so he can be informed enough to give a good sign-off.  His signature is needed though or the change won't go through.  I've rubber stamped something before just because I was added as an impact reviewer and I had to.  And the times I have tried to hold up the process so I could understand the change better, I got tons of pressure from the top to just sign-off on it so they could implement it in a hurry.  And while you can't teach managers 15yrs of SQL so they can be informed, you can't teach a DBA 15yrs of business knowledge so he can be informed either.  So why are we on the impact reviewers list then?  Let's try to trim the fat and only put people on the list who could honestly contribute.  That means that your list will change depending on what CC you're trying to push.  You can't have the same 10 people every time because they're not all relevant to all the changes.  For instance, I may be relevant when it comes to looking at code changes, but changes to business logic render me useless.  So I should be on the list for the former, but not the latter. 

Not early enough

Often times the process happens too late and nothing can be done anyway.  This has happened to me a lot.  What's supposed to happen is when someone comes up with a new idea for a change they're supposed to write it up and send it to others who know what's going on.  Then that gets approved and some other things happen, but essentially this is where the actual work begins.  Now the solution gets coded, typically in a vacuum, and then tested (sometimes).  Once testing is complete the change typically gets scheduled and the RFC gets generated and sent to all the impact reviewers.  One of the technical reviewers takes a look at the code and decides that it's done in the worst way possible and that the server is already under strain so adding to it is not a good idea and will only serve to generate more support tickets and dissatisfied customers.  The problem though is that the business people have already advertised the change to their customers and everyone is expecting it to happen on a specific date.  So when the techie guy denies the change, he gets told that there's no time to re-code it and that it has to go in as-is to meet the deadline.  And his manager basically makes him approve it anyway.  So had this CC been part of a process that actually got the techies involved early, they could have avoided this situation.  This particular situation has happened to me the most often of any of them.  In this case, the CC process is rendered completely useless because the people you've said should be making sure it's a good change are forced to approve changes they don't believe in.  And it's not a situation you can win.

There aren't any real answers to these problems unless someone sees the light.  The only thing companies have to do is start taking their changes seriously and not just going through the motions.  Sure, it slows down changes to the system, but one of the biggest problems in support is companies pushing changes too quickly without proper review and testing.  I've always called this, moving at the speed of stupidity.  It's easy to come up with an idea and code it, but that doesn't mean it should go into prod right away.  There's a difference between something you've been able to get to work, and something that is production ready.  I have this talk with start-up vendors all the time.  Software you write to help you do something in your job is far from software that's ready to be sold to customers.  Yet that happens all the time.  And internal code is the same thing.  And what happens is someone comes up with an idea and tells his boss about it.  His boss likes it and has him code it.  But just because it's a good idea, that doesn't mean that it has to go in right now.  Everyone does that.  Just because they thought of it they think that the business can't go another day without it, when in truth the company has been around for years and has functioned just fine without it.  So slow down and take the time to make sure you do it right, and only put the people on the impact reviewers list who can actually contribute to the process.  And leave yourself some breathing room.  If someone denies the change for whatever reason, you should be ready to push the date until their issues are addressed.  This is how you make people care about a process;  by actually taking their advice.  Otherwise they'll just rubber stamp everything because nothing they say matters anyway.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2010 IDG Communications, Inc.