Why Change Management

My entire career I have been working as an external IT’er for lot’s of companies and they all had their specific view on Change Management. Comparing them I can categorize them in 4 types:

Type 1: Change ManageWhat?

This is the typical approach in the smaller companies. The changes are not managed at all not that they don’t want to but don’t have the people, the budget, the know-how, the will… to do this. So changes are not managed and in most cases not even tested. The (not so) funny part is that in most of these kind of companies I was hired because something was going wrong and they had no clue where to start looking or how to start solving the issues.

Type 2: Change Management, Yes we have to!

It has to be something Belgian, we just tend to dislike rules and procedures so if some external organisation obliges us to have a Change Management procedure, we’ll have one but… the changes are not really managed. I saw companies where approvals where already given to proceed to the next step before there was an approval from the test team, changes approved before the developers finished coding and all kinds of exceptions to the procedure so that the change process had a minimal impact on the development teams. The only reason I found for these companies to have change management is that they needed to document every change because of ISO or SOx compliance.

Type 3: Change Management = Cost Management

When working with smaller IT-teams where people can wear different hats (fire brigade, architect, designer, implementor…) it’s different to manage the costs and resources. In most cases the original tasks of these teams is to support the IT environment. But after time goes by the rest op the company will start thinking that maintaining, upgrading, adapting, replacing… is also normal support from the IT department. But all these tasks are not foreseen in the budget, even worse if you let the business free, they’ll expect that the IT-department also pays for extra hardware en licensing costs. So starting up a basic Change Management procedure can help manage the cost. From the moment a request is not in the task list of the support-team it will be categorized as a Request For Change that needs an approval from the IT-manager. And after that it’s up to him/her to discuss with the other business unit managers from wich budget the change will be paid.

Type 4: Change Management to manage the changes

If this is the reason why a company starts with Change Management, there is a great chance that they will succeed to create a decent procedure. Saying we want to manage our changes is saying we want to know why, when, what… without saying we want to start a bureaucracy to discourage changes and improvement of the company. They will also keep changing and improving the Change Management process itself. Resulting in a stable and cost-efficient it-environment.


For me the most relaxed way of working is in Type 4 environments. You know what is expected from you and you know that the things you need to do are tested so the risk of problems when executing the change is relatively small. Type 3 can be the first steps to full Change Management and will already be a relieve for the people in the IT-department when their Change tasks will be planned. Type 1 and 2 are, for me, almost equal to each other only nr 2 takes more effort because of the paper work and because there are names in the documents there might be a chance that some real testing was done.

%d bloggers like this: