I recently found myself discussing the use of change models with a customer. This customer, like many others that I come across, thought that every IT change should be classified as either a standard change, or as a normal change requiring review by a change advisory board (CAB). Change models, as my customer agreed, allow change management to be much more flexible than that.
ITIL (the most popular best practice for IT service management) says that there are three types of change:
I’m not going to say any more about emergency changes here, except to note that they should only be used when you have to change something urgently to fix an incident. ITIL describes a change model as a way of planning how to manage a particular type of change – they can be used to plan any of the three types above.
I’m going to explain all about change models; but before I do that, let’s remind ourselves of the essential differences between standard changes and normal changes reviewed by a CAB.
This is a low-risk change that follows a well-documented procedure and has been pre-approved. Each standard change has a detailed procedure that specifies exactly how it will be implemented, and this includes things like:
Here are some examples of typical standard changes:
This approach to managing standard changes ensures that straightforward routine changes can be managed quickly and efficiently.
Many of the organizations that I work with hold weekly CAB meetings that review changes. Membership of the CAB often includes many different IT managers, and sometimes there may even be a representative customer too.
Usually, the changes that will be considered must be submitted a few days before the CAB meeting so they can be circulated to all CAB members and read before the meeting.
Typically, during the CAB meeting, the people who have requested the changes under consideration are invited to present their change requests to the CAB, who then challenge them to ensure that they have assessed all the relevant risks and that they are fully prepared to implement the change. If the CAB members are satisfied then the change is added to a schedule for implementation, otherwise, it is deferred until some additional work has been done.
This approach helps to ensure that big, risky changes are managed with the appropriate level of care and attention.
But what about those changes that do not fall into either of the above categories?
There are many changes that need to be implemented quickly, that are not big enough in themselves to warrant the time and effort that goes into a CAB, and yet can have a business impact if they go wrong.
Enter “change models.” These let you define how a change will be managed in advance so that most of the risk management has been done before you submit a change request. They also make it easy to identify changes that can be approved without needing a full CAB meeting.
Change models are a great way to ensure that changes have been planned well and that risks have been assessed, without delaying the implementation of changes or adding unnecessary overhead.
What you need to do to introduce change models is define models for your organization’s common change types. A change model is a workflow with supporting documentation. Each change model specifies:
The change model helps to reduce risk because for each type of change you think through everything that needs doing and then document it. You need to do this only once; but you can update the model any time you learn something new while using it to implement a change.
The change model also helps to reduce delay because, for most change models, you delegate the authority for authorizing the change to someone who won’t make you wait a week for a CAB meeting. A small number of change models may specify the CAB as a change authority, but these will just be the changes that need significant management attention.
Some of my customers use change models when:
These are just examples, but they typify some of the circumstances where using a change model helps.
Changes like these need some level of testing and risk assessment, they may need to be authorized by someone independent, they must be documented, and they may need to be deployed and released in a gradual manner.
For example, one of my customers always installs server security patches on a specific set of servers first and then waits a few days before rolling them out further. They always test a specific set of applications, but not every application, before deploying these patches. Because this is all documented in a change model they know what to do, and nobody makes any mistakes when rolling out security patches.
If you don’t already use change models, as well as standard changes, then you really should think about how you can introduce them to reduce risk, improve change throughput, and reduce the amount of effort you spend on change management software.
You don’t need to make this a big deal. Just identify one change type that this approach might work for and document the change model. Then try it out and see how well it works for you. If you like it then add another one. Eventually, you should find that the CAB has very little work left to and can just focus on discussing strategic changes – which is what managers should be doing anyway!
As always, please let me know if you try these ideas and how they work out for you.
If you’d like to learn more about how to manage changes effectively then here’s some further help for you: