I like to think of myself as a reasonably intelligent person.
I’ve been working in ITSM for many years and I understand the mechanics behind change, but it has always been one of the hardest, most arduous of processes to get right.
For those who may be new to ITIL and Change Management, the textbook definition defines change as:
"The addition, modification or removal of anything that could have an effect on IT services."
What this means is, the scope for change management could cover anything from the architecture, the processes themselves, alterations in the tool as well as physical changes to the assets themselves.
As an ITSM Architect, testing change records through whatever tool I had deployed, reviewing process documents talking about lead times into the mists of the future, I found myself musing as to why things get so complicated.
Who best to help me tackle this than a former change manager, of course!
Claire Agutter has been an ITIL® principle lecturer since 2007, involved in exam panels for ITIL V2 and V3 and provides online ITIL training through IT Training Zone Ltd.
Claire gained her practical experience of ITIL in the real world, including change management at the UK Highways Agency.
One of the dangers, when organisations implement change management is to go too deep too soon, and Claire identified two ways that change management can be utterly messed up.
She said: "One way is to not do enough and you still see changes failing, and the other is to say 'Right, you just moved a piece of paper, that's a change.'
"That will get you unpopular fairly quickly."
Do any of these sound familiar?
The following are realities, just accept it:
Looking at the last point, change management comes in at a specific point in an organisation's evolution.
Before the process, there tended to be an informal arrangement so when that immediate response is removed, it can be a factor.
Claire explained: "You only get once chance to get it right, because if you try and bring something in that doesn't work, what you then create is even more resistance because next time you try and improve things, you just get a wall of people with their arms folded.
"It tends to be a more emotional reaction to change management than to other processes, certainly from the technical staff perspective, because you've got somebody coming in and trying to tell you how to do your job."
Sometimes even the way offices are set up lends themselves to resistance.
Both of us agreed that often service management are placed apart from the technical teams, requiring a walk across office floors, building lobbies to get to the technical teams.
Claire believes that the sales pitch is wrong.
"People see change management as quite a bureaucratic process—the messages are about control, documentation, authorisation—they tend to be words that people are not particularly interested in hearing!"
The key is a high level vision.
Claire explained: "We implement changes for two reasons—to make things better or fix things, or because we need to avoid a cost or make a saving.
"Change management is about delivering those benefits, in the order that the business wants, and delivering them in the safest possible way.
"The sales pitch has to be about why we’re doing this, not what we're doing."
It is important to back with up with some context.
Some organisations would rather have things quickly that do not work very well rather than trying to implement a 16-step process, with a six week lead time.
Looking at the broader organisation context, change management is there to protect the business, and to deliver what they need.
One size does not fit all, so you need to understand what level of change management needs to be applied to different sizes of change.
It comes back to vision and doing change because it is giving the business what it wants.
Maybe look at it from a customer/consumer's perspective.
We take IT for granted until it stops working, but how much do customers have to engage with the change management process?
It is a part of an implicit trust that you have with a service provider, that they know what they are doing and that they do it in a controlled way.
We have to recognise that IT systems will fail.
Claire said: "Quite often, system failures are liked to changes, and at least if you are doing some change management, you have got a clue about what might happen, and how to roll back to a working state."
Take a look at the culture of your organisation—does it reward fire-fighting and heroes?
People love a good drama—if you implemented a change that has gone wrong, and you get to fix it, it can be quite exciting.
If it is spun well to the business, teams actually look like heroes.
It all went horribly wrong, but WE fixed it, because we're clever.
How do you move people from being reactive and getting a buzz out of it, to being proactive.
Both Claire and I agreed that we are big fans of re-using what already exists.
If you have something that works fairly well, grab it, use it, and do not re-invent the wheel.
Change itself is frightening, and most organisations get by with what they have had for the past 5, 10, or maybe even 15 years.
So when someone comes back, all enthusiastic, from their Foundation course, you come back to the resistance to try something new, or maybe try something again.
We have looked at vision, and the real reason why change management is important, but often the other stumbling block is a lack of communication.