I’ve attended quite a few change advisory board (CAB) meetings and I’m sure you’ll share my experience that a lot of these meetings tend to be lengthy technical discussions and/or lead to tangential conversations about all kinds of topics. Allowing these tangents is exactly the reason why important stakeholders increasingly avoid attending CAB meetings, and, as a result, your CAB meetings become ineffective.
But help is at hand. I attended a notable CAB meeting at a client in Denver, Colorado, some 15 years ago. I remember it well, because it was jaw-droppingly disciplined and brutal. I suggest adopting some (or all) of that client’s set of rules to transform your CAB into a BECAB – or “brutally efficient” CAB.
Please read on to find out more.
Start with Better CAB Timing
How well is your CAB structured timewise? How long do you allow for each change request? IT service management (ITSM) tools might propose a time. For instance, the ServiceNow utility that deals with running a CAB does so. However, the shocker for me is that the default value of time allotted to discuss every change is five minutes. Setting such a default value is an open invitation for debates, pontification, and wasting time that should have been spent before the CAB.
Granted, the default value is super easy to change, but who in their right mind would plan to have only 12 changes discussed in an hour? I suggest modifying that default value to 20 seconds!
Also look at the following three attributes to speed up your CAB meetings.
1. Attendance
- Attendance of the ticket owner (or their representative) is mandatory. Any change where the ticket owner is not present is rejected.
- Attendance of the service owner (or their representative) should be mandatory.
- Try to partition your CAB meetings into sections of 15 minutes, such that IT resources know when they should attend or when they can leave. This can be based on types of services (e.g., service criticality) or geography or technology (e.g., network- vs. application-related) or any other attributes.
2. Process
- The CAB owner (change process manager) starts reading aloud all informational changes (e.g., decisions by the Architectural Review Board or external occurrences that affect your IT environment).
- The CAB owner then proceeds to the changes that were filtered for this CAB and reads the number and description of the change and shuts up for five seconds.
- No comments are allowed except vetoes; any veto means rejection of the change (and possible resubmission at the next CAB).
- No comments are scribed or captured, except in the case of a veto: who vetoed and why. All comments for the change should be in the work notes before the CAB.
- After the five seconds are up, the CAB owner marks the change as approved or rejected, and moves on to the next change record.
3. Other Governance Aspects
A section of the CAB, or a separate CAB or change process meeting, should be planned to discuss:
- Reports related to the use and abuse of emergency changes.
- “Hall of Shame” reports of (a) failed; (b) “expedited” (unplanned); and (c) unauthorized changes.
- Usage of standard changes and progress towards increased usage.
- Accepting or rejecting proposed standard changes (following the same process as above).
- Providing a status of post-implementation reviews that were generated because of failed changes.
The overall governance of your change management is what should give your CAB the necessary teeth. The above points indicate you mean business and will boost change management discipline. The points hammer home that the CAB is only there to ensure communication and process adherence and is not intended to diminish the responsibility of the stakeholders.
It should be obvious that such governance and a “BECAB” can only be instigated and maintained when there’s sufficient executive support. If your CIO condones unauthorized changes without disciplinary consequences, or does not address sloppy execution, or allows meetings to be skipped on frivolous grounds, then any amount of process control is akin to putting a band-aid on a wooden leg.
I hope that you found this change management article helpful. If you have any questions, comments, or tips, please use the comments section below.
Thanks to my DXC colleagues Greg Dusault and Ian Golando for their insightful feedback regarding this topic.
Jan Vromant
Jan is a process architect, focusing on IT service management, operational governance, and outsourcing. He is an accredited ServiceNow system administration trainer, and certified in ITIL Service Management (v3 Expert level), Project Management (PMP), Governance of Enterprise IT (CGEIT), ISO/IEC20000 training and consulting, and TOGAF 9. He earned an MBA from Rice University in Houston and is a Principal Consultant with DXC/Fruition Partners.
