IT change management doesn’t always need a CAB

I was involved in a discussion about IT change management on Facebook recently. It started with a simple question about how standard changes should be documented, but it quickly moved on, the way social media discussions do. One point that I noticed was a belief among many people that all changes should fit in one of the following categories (note these are NOT the ITIL definitions, they are the usage I have seen by real organizations).

• Standard changes. These are low-risk, well-understood, fully-documented, pre-authorized changes that can be implemented without needing additional authorization. They are typically implemented as service requests, but may also include operational changes.
• Normal changes. These are subject to review by a change advisory board (CAB), which typically meets once a week and requires change requests to be submitted a few days before the CAB meeting.
• Emergency changes. These are changes that must be made very urgently to resolve an issue such as a service interruption, a significant security vulnerability, or any other need to implement a change before the CAB can meet to authorize it. Emergency changes are reviewed by an emergency change advisory board (ECAB), which meets as needed – possibly electronically.

It can be very hard sometimes to get people to stand back and think about why they are doing something, what value it is creating, and how it could be done better. In this case a deeply ingrained belief that all normal changes need to be reviewed by a CAB can blind us to the damage an overly bureaucratic process can create.

If you hold a CAB meeting once a week, and change requests have to be submitted three days before the CAB meeting, then you delay every change by up to 10 days. This might have been appropriate in the days of mainframe computers with changes implemented every few months, but in the modern world it is completely unacceptable. We have to find ways of working faster and more efficiently, to meet our customers’ expectations for agility and rate of change, while continuing to ensure we protect our IT systems from the effect of poorly planned changes. The question is, how do we do this?

One of the things you need to do is to think about how you authorise changes. Many IT organisations simply assign the CAB as the change authority for the vast majority of changes. This is a great pity, as allocation of suitable change authorities can make change management very slick and responsive, instead of slow and cumbersome.

The ITIL Service Transition publication describes the use of change authorities, and says that each change should have a designated change authority, based on the anticipated business risk, the financial implications and the scope of the change. Here is an example of how change authorities could be allocated.

Type of change	Change authority
Infrastructure changes implemented as “Infrastructure as code”	Standard change
Other low risk infrastructure changes, provided they are within an approved change window, that this is not a critical environment, and that this environment has not had any failed changes in the past 12 months	Change submitter
Low risk changes to code as part of an approved software project	Paired programmer
Medium risk changes to code	Development manager
Medium risk changes to infrastructure	Operations manager
Initiation of new software projects	Project office
High risk changes	CAB

 Of course a matrix like this can only work if the designated change authorities do their jobs properly, but that applies to almost any role in IT. The point is that you can be agile and efficient about how changes are implemented if you delegate the change authority to the right place. To ensure this is working properly you then need to make the change authority accountable for the success of the changes they authorize – but that takes us on to measurement and KPIs which is a different topic.

The reason that some people think IT change management is cumbersome and bureaucratic is because it often is, but there is no need for it to be.  Just remember: don’t use a CAB unless you really need to.

How do you assign change authorities in your organization? Is it time you reviewed this, to see if you can be more agile?

Image Credit   Maryland GovPics