4 Change Management Tips to Avoid Change Advisory Board-om

Change advisory

Do your IT service management (ITSM) change advisory board (CAB) meetings go on endlessly? Do you debate each change as if it were 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 high-level 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 change advisory management strategies and ultimately help your business leaders and their management teams succeed with their business processes.

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 advisory 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 change advisory role is

Now that you’ve wielded a stick in change advisory, 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 improvements and 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 change advisory process

Now that you have your momentum to improve your change advisory 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 rather than needing change advisory. 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 management tools and ITSM processes (in service operations terms) for managing your IT environment and services. A successful implementation of the four tips above will make the CAB a valuable meeting that reviews only those changes that need attention.

You’ll be able to handle greater volumes of change advisory with increased safety and significantly less failure. The acid test is whether you can invite your business colleagues to the meeting and the team members are confident that they both understand what’s happening and get value from it.

Image Credit

Want to read about the ITIL 4 service value chain or ITIL capabilities, such as effective and efficient incident management and knowledge management to improve service delivery?

Please use the website search capability to find more helpful ITSM articles on topics such as knowledge bases, customer satisfaction, ITSM roles and responsibilities, taking a structured approach to ITIL, CAB member responsibilities, customer experience (CX), real-time employee experience (EX) measurement, reduced costs from automation, enabling business operations, digital transformation, service management plans, and meeting business goals.

Duncan Watkins Photo
Duncan Watkins
Senior Consultant at Forrester

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.

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

nl subscribe strip imgage

More Topics to Explore

7 Responses

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

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

  2. 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)

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

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

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *