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

  • 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.

  • 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 CAB would meet for the widest-impacting/ cross-department type changes (thus limiting the number of Changes they have to deal with)

    • 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

      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 changes that need wider discussion, so a CAB would be appropriate. Apart from some permanent members for each (set) of changes only the people who were able (because of their position in the customer organization of because of their knowledge of the technical aspects) attended the discussion of a particular change. CAB meetings were meetings where people popped in en out the meeting just to give their opinion where strictly needed.

      Creating different perimeters (functional of geographical) as Askay suggests may also reduce complexity, provided that very good analysis is done on the (absence of) cross perimeter consequences

  • 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.

    • 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…”.