Why should I implement a change management process in my company?
Every company naturally develops what I call informal change management. It is usually very rigid, conservative, built on habits and people. It’s therefore awfully difficult to update and adapt to changing situations. In reality, this means that changes are more difficult to enforce and implement in a controlled manner. It’s like a nine-headed dragon, where you deal with one thing from the perspective of one branch of the business, but other areas suffer because you aren’t able to do it systemwise. There are several dangers in this kind of situation. The first snag is when you lack due process on the business side. Any staff change will cause a problem. The new person is not familiar with informal change management, and either the established procedure becomes hard to acquire (whom to call, whom to turn to with a request) or they’ll start to create one all over again. It’s just going down blind alleys that delay you and tie up people’s resources.
The second snag is lacking process on the IT side. Although I might have a structured approach from the change initiators, there’s no clarity about who is to implement that, on the IT side.
One day it might be development, the next time operations, the third time someone else. Alternatively, they’ll just play ping pong, where one team tries to pass it to another. Making a change won’t be standard, sometimes implemented in 3 days and the next time in 14 days, all depending on how IT feels.
As a result, you’ll meet lots of other subsidiary problems, such as lack of prioritization, poor business awareness about the change status and progress, poor capacity management, etc.
What should I watch out for if I am introducing change management?
You have to keep in mind that change management can’t be done halfway. For it to make sense, it must be duly followed through. Without the support of management, you can’t enforce it. For example, I experienced a change management implementation that received ISO 20000 certification, and yet it was a failed project. It was a project without managerial support, where the assignment basically read as follows: “We just need to go through an audit and get certification.” So, the process was just put away in a drawer to be pulled out once a year and presented to the auditor. In reality, however, everything continued to run outside the formal process. It doesn’t take long for some troublemaker to find out he can do things the old way and get away with it. You can make a ‘Potemkin village’ (put up a dummy facade), but if you don’t convince the business, you’ll get a failed process, albeit with ISO 20000 certification. Changes will continue to be pushed through informal channels.
Without the support of the management, there is still a risk that the project won’t complete. The initial effect will usually be worse quality, less capacity, greater cost. That’s the generic problem with IT projects. You need to be prepared that things can get worse initially and understand that we have to get over this phase for the benefits and improvements to come.
This brings us to the management of expectations. As soon as things take a downturn, temporarily, the team comes under pressure. How do you proceed in such a situation?
Expectations about an established process should be different than those straight after an implementation. Even in the post-implementation phase, I can achieve some quick wins. In change management, these are typically standard, pre-approved changes. That’s how I always help myself. We identify a relatively small, often an ongoing change, which has a high error rate due to an unsystematic approach, or is hampered by bureaucratic obstacles. If we define the standard change well, describe the workflow and guide the change events to do it, we’ll achieve a quick win, which the customer perceives positively, and can be used to show the process is meaningful and demonstrably frees up a degree of team capacity.
For instance, I dealt with a process for a car manufacturer, whereby the cars themselves automatically call the emergency line in the event of a crash,
from anywhere in Europe. If the emergency number at some given location changes, that information has to flow through to all the systems. There is no need to approve such a change and burden it with bureaucracy. We decided that such a change would be approved in advance, and we set up an automated workflow that triggers requests to the telephone operator, the database. This eliminated a lot of manual work. But you have to prepare the change implementation process well.
When I implement the process, how do I verify project success?
In general, when I prepare a project, I also prepare the metrics by which I will evaluate the project. This also applies to the implementation of change management. Metrics will be subjective and objective (soft + hard). The subjective ones are very important. It is about business and IT satisfaction with the course of the process. Through questionnaires and interviews, I get a clear idea of how satisfied with the current process people are. After implementing the change, I will make the same assessment, even with the scoring of each change, and evaluate whether there has been a positive development. Another soft indicator can be how often management summons you for an earwigging, how many escalations and complaints there are. Here, too, you can calculate to some extent how things were before and after the implementation.
Of course, you also measure some hard indicators, which are more clearly provable and are more telling, persuasive to a greater degree. For example, you measure time to market, i.e. the time that elapses from the change request to implementation. Most of the time, you’d measure separately by category and priority of changes. How quickly can I implement urgent changes? How quickly can I do minor changes? Then I can track the error rate in the changes. How many times have I had to roll back a change? How often did I have to re-implement, with multiple attempts? These are the numbers that will show you if the change process is working and what the improvement is, compared to the state before the implementation.
How do I then ensure that the process does not die a slow death and the company doesn’t backslide into informal change management?
ITIL® talks of the principles of long-term direction and administration (IT governance). There is an intermediate link between theory (writing rules) and enforcing rules. These are procedures that you have to create, along with the process itself. Their task is to ensure control of the process, subject it to review, and create pressure to carry it out. If you do a process without governance, you won’t even notice that it doesn’t work or that it’s been bypassed. When you use the principles of IT management, you might create e.g. a regular report that shows what percentage of requests have passed through the formal part of the CHM as opposed to informal channels. Basically, already when you implement the process, you set up a control mechanism of what will happen if this part is higher than, say, 10% of total. The consequence is usually that some specific problems get resolved at the managerial level. This way you ensure that the theoretical, administrative portions of the process come to life.