Do your change advisory board (CAB) meetings go on endlessly? Do you debate each change as if it was the first time anyone had seen it? Do those changes sometimes contain language that no-one understands, even the change proposer? If you’ve answered “yes” to any of these questions then well done, you’re just like many other organizations doing change management.

These are some, but not all of, the common issues organizations suffer when they grow in size without changing their change management processes. However, help is at hand with some ideas on how you can improve and ultimately help your business succeed.

1. Require change approvers to adequately review changes before approving

In order to ensure changes aren’t being put through without due care many organizations make senior managers or even CIOs approvers on changes. However, these people are often “time poor” and, as such, blindly approve changes that they know they need without due consideration. Even worse, when the practice comes to light during an audit, I’ve seen some senior managers pull up the change creators for the error rather than taking responsibility for their own part in the situation.

An impactful way to start fixing this issue with your change process is to pull up approvers (however senior) on their mistakes. When issues are highlighted at this level it’s amazing the amount of support you’ll get to fix things. No senior IT manager wants to be responsible for a minor (or even major) non-conformance point during an audit, so use this “stick” to build momentum for your change management improvements. Even better, once change approvers are focused on change details, the change management process owner is no longer alone trying to audit the sea of changes that are needed to run a modern business.

2. Ensure change approvers are clear on what their role is

Now that you’ve wielded a stick, you can get out the carrot. Unless all of your change approvers have been heavily involved in drafting and creating your change process it’s possible that they’ll have questions and misconceptions about exactly what their role is. In order to overcome this, it’s necessary to educate them in some way. The method will depend entirely upon the resources that you have available and the complexity (or otherwise) of what you’re doing. This may simply be documentation explaining the role of a change approver with some FAQs, or it can be a half-day or even a full day’s training. It’s up to you how you implement this, but you cannot rebuke approvers for failing to adequately review changes prior to approval without explaining what they actually need to do.

Once you’ve put this in place you need to think about how you deliver this to new hires, as well as to anyone transferring roles or explaining process updates. A key part of IT service management (ITSM) is continual service improvement (CSI) and change management is no exception to this. Therefore, thinking about how to keep this understanding up-to-date and relevant for change approvers is fundamental.

3. Engage with change approvers early in the process

Now that you have your momentum to improve your change process you need to maintain it. One of the key ways of doing this is to get change requesters to engage with change approvers early in the process. If you’re using Agile or DevOps principles for driving change, you’ll already be engaging with the business to ensure that what you deliver is of value. It isn’t a giant leap to ensure that when an approver is different to those you already work with; you engage them too. By doing this you’re encouraging employees to use the CAB for its actual purpose, which is to schedule changes effectively and avoid potential conflicts. The change advisory board isn’t called the change approval board for a reason – that’s not what it’s for!

4. Create standard changes

How often do you review the same changes and no one objects? When this happens you have to recognize the need to create and automate standard changes. Standard changes are those changes to services or infrastructure that are pre-authorized, i.e. the approval is automatically granted. However, in order to qualify a change for this you have to remember and review the following:

  • Has it met your accepted and agreed process for creating a standard change?
  • Is the change repeatable?
  • Is it low risk?
  • Are the activities well known and adequately documented?

A word of warning though – it’s possible that your organization might want to include changes other than those that are low risk, but this should be properly considered beforehand. By introducing a change without manual approval you’re automatically increasing the risk, however slight. To include a medium risk change may well be one step too far.

The CAB is one of the most powerful tools to manage your IT environment and services. By implementing the four tips above you’ll be able to make it a valuable meeting that reviews only those changes that need attention. You’ll be able to get through greater volumes of change with increased safety and significantly less failure. The acid test is whether you can invite your business colleagues to the meeting and be confident that they both understand what’s happening and get value from doing so.

Image Credit

Want ITSM best practice and advice delivered directly to your inbox? Why not sign up for our newsletter? That way you won't miss any of the latest tips and tricks.

Senior Consultant at

Duncan Watkins is a Senior Consultant at Forrester Research. Within the space of ITSM he specializes in service strategy, service transition, and continual service improvement (CSI). Although his approach is based on best practice, over 20 years in the industry has allowed him to forge a pragmatic real-life approach to technology.

More Articles That You May Like

7
Write Your Opinion

avatar
3 Comment threads
4 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
  Notifications  
Newest   Oldest 
Notify me about
Matias Piccione
Matias Piccione

I believe that you have confused “Standard Changes” with “Routine Changes”. The later are the ones already “pre-approved”. Standard changes may evolve in routine ones as you suggested in your article.

Stuart Rance

It would be interesting to learn the source of your terms “Standard Change” and “Routine Change” Matias. I am familiar with the ITIL usage, which is different.

ITIL defines “Standard Change” as “A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction…”.

Akshay Anand
Akshay Anand

I think the word “Board” is taken too literally (like the “Board of Directors”). Any such groups are essentially made up of the most competent group of people who can make a decision. So why should there be just ONE Change Advisory Board for the whole organisation? Have an Infrastructure CAB, an Application CAB, and so on. Minor releases could be handled by team leads or through standard change pre-approvals. An Application CAB, for example, could look at authorising a major release, and could be made up of the Product Owner, Service Owner(s), Application Architect & so on. The higher-level… Read more »

Duncan Watkins

Again, I agree. Multiple CAB’s are a good thing as long they contain relevant individuals. Often though the trick is to make sure people don’t ‘elect’ themselves to every board.

Peter Gerritsen
Peter Gerritsen

I’m was in the past used to a situation (which worked well) where: – there are a lot of standard changes. The only thing the change manager want with standard changes is to be able to track them in case something goes wrong. So, recording them in the change database AND making sure Configuration Management is updated! – there are a lot of changes where the change manager himself can decide based on his knowledge (and risk estimation) of the organizational and the technical aspects. He may if needed consult one or two people – there is reduced number of… Read more »

Stuart Rance

The most important thing you can do to improve CAB meetings is to reduce the number of changes that they have to deal with. I tell some of my customers that the CAB should only have to review 2 or 3 changes a month. Every other change is better reviewed by a different change authority. For example in one organization minor code changes can be reviewed by the paired programmer, and most infrastructure changes can be reviewed by the data centre manager.

Duncan Watkins

Totally agree Stuart. It’s all about what’s an appropriate level of review. The employee/team responsible for the particular area (such as you infrastructure example) are often best. Organizations often fall down because of a lack of trust, creating a situation where sign off by committee avoids blame when things go wrong.