If you're already versed in the changes to the traditional IT Service Management (ITSM) best practices that came with ITIL 4, you'll know that Change management is now called change enablement, and there's minimal mention of the Change Advisory Board (CAB).
But what does this mean for your IT organization? Do we still need the Change Advisory Board? Should we drop the CAB (if we had one)? Should we ignore ITIL 4's new change enablement guidance? Or, better still, how should it best meet current and future business needs and manage the changes required to meet them?
To help, we consulted 19 ITSM industry leaders to understand whether it would still be useful, and how it'd be best implemented to fulfill its role.
But before we start, keep in mind that this article isn't intended to provide your organization with "the exact answer" to how it does or doesn't employ a CAB in its broader change enablement practice. Instead, it's intended to provide a variety of opinions and experiences that will help you and your colleagues formulate the solution that will work best for your organization.
Do we still need the change advisory board?
There's a school of thought that it was never CABs that were wrong but rather how individual organizations adopted the CAB concept — both in terms of the types of changes presented to the CAB and how CABs functioned. For example, the division between "standard changes" and those that needed extra assessment; but still the latter changes don't necessarily need to be presented to a CAB.
When asked, all the leaders seem to agree on one single idea: something is needed, even if the "what" is still to be decided. The reasons behind this contemplate the following points.
The first motive to why a Change Advisory Board is needed is to acknowledge that it was always the "means to an end." However, it is in no way the only means to achieving that end. Ultimately, it's essential to focus on the desired outcomes when deciding how best to enable change.
"It didn't matter whether you have a CAB or an automated tool. It’s all about the function that needs to be secured. The CAB is one but not the only mechanism."
- Alan Nance, Co-Founder and President at XLACollab
“CABs stop the corridor conversations and the changes that bring an organization to its knees.”
- James Finister, Engagement Director at Tata Consultancy Services
But saying that "it was the means to an end" can also imply that it had to be there. It was the official recommendation. And thus, the Change Advisory Board name is likely forever tarnished thanks to CAB overuse and overly bureaucratic change practices.
However, this doesn't necessarily mean it's pointless. Just remember this when seeking new ways to fulfill the CAB’s intended purpose in the future.
"The name is contentious, but who would disagree that we need to talk about change? The 'kill the cab' lobby was symbolic, but most organizations and sensible teams still need to meet and support change and assess risk, impact, etc. I think that was all reflected in ITIL 4. Most organizations I work with still have a CAB or something similar, or they meet and talk."
- Barclay Rae, Consultant at Barclay Rae Consulting
"You never need a CAB as described in ITIL. Ask the development community what they think about CABs! CABs belong in history as an example of how ITSM put a straightjacket around agility and innovation."
- Kevin Holland, ITSM and SIAM Consultant
The third reason why we still need the Change Advisory Board is that it was always supposed to be a level of authority, not the one and only level. Therefore, its role takes up just a part of the change management process.
"I only ever saw the CAB as a catch-all description of the process of 'asking people who might be affected, or help me get what I’m doing right, or stop me breaking something important before I actually do it.' However, you do this as a CAB. 'Change' is a good word – it sets out what your scope is. 'Advisory' is a sensible word – asking for opinions and advice but not being bound to take it all on board. 'Board' is a damn silly word."
- Ivor Macfarlane, Consultant
"Teams that release code many times a day should not be using a CAB for those code releases, but those same organizations may be doing other more significant changes that affect many teams and potentially the entire organization. For example, if the team wants to migrate from one cloud service provider to a different one, this may need wide discussion if it affects contracts at a strategic level."
- Stuart Rance, Consultant at Optimal Service Management
We mentioned before that since the CAB was included as an ITIL guideline, it kind of had to be there. Thus, it's the organization the one that needs to do a bit of introspection and analyze the reason behind its existence.
If there's none (because they always say "yes"), then question if it's needed.
"If a CAB can't prioritize changes, and assess the risk of implementation against the risk of not implementing, then what are they there to do?"
- James Finister, Engagement Director at Tata Consultancy Services
"We've (Lloyds Banking Group) been on the BBC website front page because of changes gone bad; we've equally avoided it by CAB scrutiny of high-risk changes."
- Gareth Davies, Technology Service Improvement Consultant at Lloyds Banking Group
Lastly, CAB meetings might still be helpful to have if that's what your organization needs. If not, you should adjust your change approval structure to whatever that is.
In Agile worlds, some would argue that both the CAB and the change manager have no role. If necessary, though, and for many organizations at least a change manager will be, remember that the CAB and the change manager fulfill different purposes.
"Years ago, I implemented change management at a scientific organization. We called it a 'peer review' in our comms, which is a well-respected process. I now emphasize 'asynchronous, online collaboration' to achieve the bulk of the evaluation and support for a change. I reserve my 'big meeting' for changes that need the widest consultation, are complex or contentious and for which a face-to-face 'workshop' would be best to arrive at a consensus."
- Dean Toovey, Principal at Conduite Pty Ltd
"If the change manager was in touch with the right people and had visibility or knowledge of configuration item relationships and resource scheduling, they should be successful alone with discussions as needed."
- Jeff Pitts, IT Service Desk Coach at Johnsonville Sausage
As you can see, there are several reasons why the Change Advisory Board might not be entirely out of fashion. However, what it does need is a bit of reflection. CAB meetings have been overused and created just because they were part of a process, leading to a lack of purpose and meaning.
So, despite the ITSM experts' opinions, it's crucial that you analyze your organization and the role it plays to truly understand if it's still needed — and if the way it's been conducted requires adjustments.
If that's your case, keep reading because the consulted industry leaders also provided considerable insights to do it right!
10 insights related to the CAB’s operation
If your organization still needs a CAB-like capability (perhaps a meeting with a different name) then the key is to ensure that it's allowed to function as a valuable business capability.
In order to successfully operate the CAB, or whatever the physical or virtual collaborative decision-making capability is called, the 15+ experts we consulted shared some light on the most essential aspects of its development.
For ease of communication, the term CAB is still used to represent a corporate change enablement capability that might be called something else.
The first step to running an effective Change Advisory Board is to understand how a well-used and well-run CAB (or whatever you wish to call it) will add value, with relevant information regarding a change shared in order to analyze key aspects and make informed and valuable decisions.
"You don't need a 'CAB' (you never did, really). What you need is an approval mechanism that enables changes to receive the appropriate authorization from the appropriate parties, which can be done via any method that works for your organization. If you can do that between two parties in a Teams chat, great. If it takes a room (or conference) full of people that are actually checking their email and filling the conversation with 'I'm sorry, could you repeat that?' then you missed the point in the first place.”
- Michael Keeling, Service Management Lead at DXC Technology
“The regular boredom-torture sessions attended by all, unless they can get out of it, is a highly dangerous alternative to having a proper change schedule. A small relevant group of experts and stakeholders considering risk, mitigation, and value for a few important changes ad hoc is an extremely valuable exercise.”
- Peter Brooks, Service Governance Consultant
As opposed to post-mortem meetings (which have the risk to become a place to blame people for whatever went wrong in a project), the CAB can easily become a way for no one to be accountable, or too often, even responsible.
To avoid this, you must assess the accountabilities within it.
"The original intent of a CAB wasn't to assess the change itself. It was to assess the risk and impact of a change in a wider context."
- Akshay Anand, Principal Pre-Sales Solution Engineer at Atlassian
"A successful change process needs a strong/influential change manager, who should have the accountability and responsibilities to succeed in the role. However, most organizations don't seem to understand how this can (and will) improve the value of IT services to the organization. Hire the right person, and it will significantly increase the probability of success."
- John Custy, Consultant
In order for a CAB to work well, you must have all the right people in the room. Likewise, having the wrong people participating can be damaging too.
"ITIL v2 started the CAB obsession, saying that 'decision irrelevant' people like the capacity manager and the problem manager needed to attend the CAB. And that the decision was the Change Manager's. It seemed good at the time, but in hindsight it wasn’t and has probably done more to harm ITIL than any other construct."
~ Kevin Holland, ITSM and SIAM Consultant
"In my experience, getting advice beforehand only from senior management means you miss out on a lot of potential common sense."
~ Ivor Macfarlane, Consultant
Learning from previous experiences is crucial in every aspect of life — including CAB meetings. Look at your previous coverage. For example, were the meetings more about release and deployment communication than change enablement? It's not an issue if they were but give the forum a more appropriate name and, since you have "all the players in the room," what else needs to be addressed?
"My experience is that a CAB simply cannot judge other people's changes for quality and technical risk. However, they can highlight business risk and provide governance on things like communication plans, which any change to the way people work will need. Thinking a CAB can stop a change going wrong is long-standing ITIL-urban-myth."
- Richard Josey, Lead Service Management Solution Architect at AFJ Solutions
"In many cases, high risk/high impact changes are being coordinated and managed as part of a project or program of work; the scope isn't just technical, and there are impacts to contracts, to internal users, or external customers, and there's a need for better comms, etc. In which case the project/program steering committee is a CAB."
- Akshay Anand, Principal Pre-Sales Solution Engineer at Atlassian
ITIL 4's change guidance covers the need for change roles to be carried out. However, it does not indicate that people equate a "role" to a "unique named individual.”
It’s similar to Agile, where the whole team is the "change manager" and the "CAB," thanks to the concept of collective responsibility, with very few defined roles. ISO/IEC 20000 Part 1 also describes what should be done without ever mentioning roles.
"Many of my customers choose to keep a CAB for discussing major changes that affect multiple groups, but they delegate authority for most changes to the people doing the work."
~ Stuart Rance, Consultant at Optimal Service Management
"The context of the risk from a developer's perspective is different from that seen by the change authority that is aware of all changes. This may not be true in a small operation, and it might be quite fine to train developers to understand risk better and enable this to happen safely."
~ Peter Brooks, Service Governance Consultant
Even though many organizations aren't quite there, an effective CAB in an effective organization fulfills a governance role. If that's not the case, the CAB has to make value judgments because no one else can with authority.
"What a CAB can do is canvass views. The CAB members were never technology experts – something was wrong if they were, but they were part of governance and the people to hold accountable."
- James Finister, Engagement Director at Tata Consultancy Services
"The point is (and always has been) recognizing that changes of any kind, by their very nature, are potentially disruptive and have inherent associated risk. So, ultimately, it comes down to effectively managing that disruption and risk, and how an organization chooses to do that. In some cases, it might be a CAB."
- Ken Wendle, Author & Speaker
"In the DevOps world, it is considered wrong that a bunch of people in a room offering their considered opinion on a change could ever be as effective as a resilient toolchain with inherent safety checks. However, DevOps is struggling to achieve critical mass in the complexity of the enterprise, and one reason for that is that the visibility, from within such a toolchain, of the wider blast radius of a change, is often limited. So I think change enablement remains very important to bridge that information gap, but not via anything perceived to resemble an old school ‘let’s discuss this change’ meeting. I’d advocate even retiring the name 'CAB' because of its perception problems and shifting to something more dynamically focused on enabling each 'production line' of code changes to function safely and productively in the wider, complex context in which it exists. That's a valuable and differentiated role which we can offer from the ITSM perspective."
- Jon Stevens Hall, Principal Product Manager at BMC Software
It's not enough to question the role of the CAB in your organization. While you're at it, make sure to question whether your company also needs to reevaluate the overall change flow.
"I am all for what the CAB is supposed to represent. I just want to ensure that flow is not stopped because of a meeting that does not contribute to that flow or benefit in terms of improving/ensuring quality, security, etc."
- Daniel Breston, Consultant
"In a scrum world, for example, the sprint demo replicates many of the activities and decision making of a CAB meeting. And whomever in the product team has gotten the responsibility of change recordkeeping would be doing many of the tasks of a change manager. What we should be educating teams on is that there is often no need for a SEPARATE CAB and Change Manager."
-Akshay Anand, Principal Pre-Sales Solution Engineer at Atlassian
Many organizations just rushed out and did what they thought the book or their course instructor told them. But by doing this revision process, you can acknowledge the fact that CABs were hurt by the lack of clear guidance in ITIL when it first came out, and improve the process.
When you do it, don't forget to tie your CAB, or whatever you use, to the agreed purpose and desired outcomes.
"The lesson here is don’t prescribe processes, or roles, or templates."
- Kevin Holland, ITSM and SIAM Consultant
"What struck me as most wrong is people only putting changes in front of a CAB at the last minute, and project go-lives circumventing the CAB anyway. I liked the message that changes going to CAB didn't have to be restricted to code releases. I was never really happy with either of the A words. I don't like a board having authority, but I don’t like the advisory alternative. And Board was definitely wrong. Part of me thinks this is also down to our misguided attempt to break service management into discreet processes. The CAB function rests with the senior IT team."
~ James Finister, Engagement Director at Tata Consultancy Services
Remember that if a change is implemented via a mature CI/CD pipeline, with good testing and governance built in, it's a standard change. So no CAB visit is needed.
On the contrary, if a change is new, novel, high risk, etc., get everyone involved in a room (physical or virtual) to 'whiteboard' the right approach to implementing the change. Call it a swarm, a change strategy brainstorming session, or anything that gets people to turn up with their brains engaged.
"1. BUSINESS executives need a mechanism for approving the introduction of and major changes to business services before any work is done. 2. IT needs authorization for major infrastructure changes before any work is done. 3. Approval for the deployment of major and minor changes needs to be right-sized. This is where the CAB needs to be replaced with pre-deployment conversations between teams and final approval online as well as lower-level department approvals. Only major changes that cannot be approved online should come to a body to approve, and there should be so few of these that they can come to a daily standup for discussion and approval. We are not babies — good deployment practices should not require a weekly two-hour meeting. That's not agile enough!"
- Phyllis Drucker, Consultant
"We get immature behavior from people when we treat them like children. The highest performing teams self-certify change. It's entirely possible in a humane, properly designed system of work."
- Rob England, Executive Assistant to the CEO at Teal Unicorn
No matter its name, the Change Advisory Board or whatever your organization ends up with for its replacement must deliver against what your business needs.
"What is a Scrum team but simply a type of change authority/product CAB? Appropriate SME input, e.g. Devs, Testers with empowered business input (Product Owner), and a change facilitator (Scrum Master). I've been calling Scrum an (application) change model for years, and user stories are standard change requests where the team can approve them locally, without requiring external consultation."
- Dean Toovey, Principal at Conduite Pty Ltd
"It is possible to change this CAB culture, but it takes time, effort, and commitment from senior management."
- Stuart Rance, Consultant at Optimal Service Management
"Someone still has to assess the long-term success and failure and make strategic calls based on our actual change management capability. The CAB is dead. Long live the CAB!"
- James Finister, Engagement Director at Tata Consultancy Services
Final thoughts
If you were wondering whether you still need the Change Advisory Board — despite it barely being mentioned in ITIL 4 — the short answer would be: it depends on your business needs, but it's quite possible that you do.
Naturally, you'll be the only one that has the final word for your particular case, but in general terms, some sort of CAB is necessary for the change process. You might want to rename it, though, since its name has too much history and you'll find that people already made up their minds about it.
So, for you to shake off the past, if you decide that this type of board is helpful, it'd be a good idea to change its name and invite people to form their opinions once more than to deal with whatever resistance there might be.
To help you implement it with fresh eyes, the 19 ITSM experts we consulted provided a series of insights to consider for its successful operation:
- Agree on the CAB's purpose and desire, align it with your company's needs and make sure it adds value.
- Define key players and responsibilities.
- Learn from previous experiences.
- Re-evaluate change flows along with the CAB meeting itself.
