I'm sure that many people have had to endure the torture that is a change control process. In short, change control is a process whereby changes to a system have to be approved by a change control panel.
Generally, the panel is a group of people who probably don't know about the system and/or don't much care about it so you have to be quite vocal in why and change might be needed.
The actual ideal behind change control is to moderate changes to a system in such a way that should a system fail or have problems it should be possible to use the change control tool to work out what recent changes had been applied and undo those changes or research/test to see if those changes could be the root cause the issue. Sounds ideal doesn't it? In reality it never works that way.

In the long run a change control tool can actually do more damage that it's designed to prevent. How come?

Let's say that you have a website which has a fairly minor bug. Let's say that you know that the change control process will take two weeks to follow it's winding path and that you will need to invest about four hours to write and represent what is, at best, a 20 minute change.

What do you do?

Do you spend the time and fix the bug or do you forget about it and press on with the several hundred other things that's on your list?

Let's say you pick the second option (and I don't blame you if you do because I've done that) and several months later that small issue could explode to be a big issue.

And that's why change control systems need to be as flexible as possible otherwise what appear to be minor changes will be quietly shelved and in the long run that can lead to a major incident.

I'll provide some suitably altered real world examples in a future article.