IT change management doesn’t always need a CAB

A typical 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


 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

comments powered by Disqus

Optimal Service Management Ltd.

7 Ingatestone Road, Woodford Green,
Essex, IG8 9AN, UK

Registered No: 8791379 England

Phone: + 44 791 3344 143

Recent Posts

  • 2022 02 15 Risk appetite
    Defining your risk appetite

    How to create simple definitions of risk appetite levels, and then assign these to each of your organization’s projects, services, business units or any other clearly identifiable part of your work.

  • 2021 11 25 Mentoring inage
    Mentoring 101

    Mentoring is a great way to develop both professionally and personally, and the mentor can gain as much from the relationship as the mentee. This blog gives an overview of how you can get started as a mentor, or as a mentee.

  • 2019 09 11 A great customer journey has to be planned from end to end
    A great customer journey has to be planned from end-to-end

    Have you tried mapping out your customers’ journeys? If not, then it’s an exercise well worth doing.

Latest Tweets