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

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

comments powered by Disqus

Optimal Service Management Ltd.

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

Registered No: 8791379 England

Phone: +44 20 8504 2002

Recent Posts

  • 2018 08 08 How to manage major incidents and security breaches IMAGE
    How to manage major incidents and security breaches

    Major incidents and security breaches are different. Learning from experience can turn out to be hugely expensive, or even result in the organization concerned going out of business. So how can you make sure that you handle these incidents correctly first time?

  • 2018 07 21 How to get the best value from an ITSM consultant IMAGE
    How to get the best value from an ITSM consultant

    I deliver much better value to some of the organizations that I work with than to others, and I’ve been thinking about why. Here are four tips that will help you to get the best possible value next time you engage a consultant.

  • 2018 06 08 Which ITSM framework is right for your business IMAGE
    Which framework is right for your business?

    At the Service Desk and IT support show, there was a panel discussion titled "Which framework is right for your business". I was pleasantly surprised by the sensible conclusions reached...

Latest Tweets