Change Models: For When a Standard Change Is Not Flexible Enough

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:

• Standard changes
• Normal changes
• Emergency changes

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.

Standard Change

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:

• Who is authorized to request this change?
• Who is authorized to implement the change?
• When is the change allowed (which days and times, or at what point in the business process)?
• Which services, systems or other configuration items (CIs) are included in the scope of this change?
• What are the exact steps that should be followed?
• What variation is allowed in following the steps?
• How is each instance of this standard change documented?

Here are some examples of typical standard changes:

• Installation of an approved software package on a desktop or laptop PC.
  • This may be requested by any user, but their manager may have to approve the budget for the software license.
  • This change is allowed at any time, but only on generic user desktop and laptop PCs, not on other PCs that are part of production environments.
  • Users submit a service request to initiate the change and thereafter workflow and installation are automated.
  • The change is documented as a service request in the IT service management (ITSM) tool.
• Replacement of a faulty disk drive in the data center.
  • This may be requested by anybody in the storage team, and no other authorization is required. However, implementation is restricted to specified times, for example, it may be allowed only on Sunday between 11:00 and 15:00 each week.
  • The scope includes all disk drives in the data center provided that they are part of fully redundant RAID arrays, so that there is no business impact from the failed disk drive.
  • There is a detailed procedure, documented by the disk array vendor.
  • Submitting an incident ticket of type “Faulty disk drive” initiates the change, and it is documented as an incident in the ITSM tool.

This approach to managing standard changes ensures that straightforward routine changes can be managed quickly and efficiently.

Normal Change Reviewed by a CAB

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.

The Missing Option: Change Models

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:

• Who can request the change?
• How should the change be tested?
• What other assessment is required before the change can be authorized?
• Are there any dependencies that should be considered?
• Who can authorize the change?
• When is the change allowed to take place?
• What steps should be taken to implement the change?
• Who is responsible for carrying out each step?
• What should happen if the change goes wrong?

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:

• A new security patch has been released for a server operating system
• A new security patch has been released for a client operating system
• A developer has written an incremental improvement for a non-critical application
• Government or other authorities have changed a tax rate

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.

What Next?

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:

• Defining metrics for change management
• Defining metrics for problem management
• Defining metrics for incident management