The CAB is Dead. Long Live the CAB.

Share twitterlinkedinmail

Can today’s IT organizations balance agility with stability?  Is IT capable of responding to ever-changing business needs in a timely, dependable, and appropriate manner?  Can IT have an intelligent discussion with its business colleagues about developing and delivering solutions, with appropriate management of risk? Can IT provide demonstrable business value at the right cost?

These are the big questions for many IT organizations.

Can business rely on IT? Is IT even relevant?

These are the bigger questions that the business is asking.

Much of the answers to these questions depend upon IT’s ability to effectively manage changes. To remain relevant, the ability for IT to manage change is critical.   Why then are so many IT organizations so resistant to change management?

When IT people hear “Change Management”, many think “CAB”

One of the core constructs of most ITSM change management implementations based on ITIL®[1] is the Change Advisory Board, or CAB.  In many organizations, the CAB has historically been a source of frustration, not only for the people directly involved with the CAB, but also for the business.

A CAB is just a group of qualified people who are to provide advice regarding a proposed change.  The idea is to have the appropriate people review the appropriate requests for change and make recommendations.

Honestly, I think the intention of a CAB is a good idea.  The primary intention is to prevent the organization from shooting itself in its metaphorical foot – and provide an objective evaluation of a request for change.

But in many change management implementations, the CAB is being used, abused, and otherwise mistreated.

The reason why most CABs are in such bad shape is that the change management process design and implementation is incomplete.   What I frequently find with underperforming CABs are the following issues:

  • There is no transparency – requests for change go into the “black box”, and (maybe) reappear sometime later.  Change Schedules are not published outside of the CAB.
  • Every request for change – large, small, trivial, ginormous – is dumped onto the CAB. Or worse, the CAB gets ignored.
  • Roles are not clearly defined, and as a result, no one really understands what they should be doing.
  • CAB meetings are conducted with few, if any, prepared to have a productive meeting.
  • Requests for change are haphazardly prepared, omitting critical information that would be helpful in the evaluation of the request.

Many CAB meetings have turned into exercises in bureaucracy, frustration, and ineffectiveness.  As a result, some within IT organizations have looked to other approaches for managing changes.

The CAB is Dead – Or is it?

First, the CAB is not the end-all, be-all for managing changes.  The CAB is just one type of change authority that ITIL discusses.  Furthermore, ITIL isn’t the only methodology that utilizes a change authority to manage work.   Other methodologies also employ similar constructs to control, authorize, and publicize changes.


Scrum uses a “task board” or “day board” to depict the “backlog”, or work needing to be done but not yet assigned.  A Scrum Team conducts a daily stand-up meeting to review the day board.  The function of the day board is to facilitate the identification of and agreement on what work (changes) is going to be done, who is going to do that work, and ensure that all stakeholders are aware of the work that is being done by whom.

In an effort to scale, many organizations that leverage scrum have implemented a ”Scrum of Scrums” or a meta Scrum[2] , but the basic concept is still the same. The meta Scrum consists of representatives from each scrum team.  Like the Scrum Team, the meta Scrum uses a day board to depict a backlog and gain commitment of what work is being done that day and by which scrum team.


A core Lean concept is visualization of work.  To ensure the visualization of work, Lean uses a Kanban – similar to a scrum “day board”, but with an emphasis on limiting work-in-process by pulling (not pushing) work through a process.  Like Scrum, many teams using a Kanban conduct daily stand up meetings to discuss work and any blockers that the team may be encountering.

As such, Lean may view a weekly CAB meeting as “waste”, in the form of non-value-added wait time.   Having said that, many factors would have to be considered before coming to that conclusion.

Think about it

I’m not here to defend ITIL – just like with any methodology, ITIL has its faults.  But it’s not ITIL’s fault that a CAB isn’t as efficient and as effective as it could be.

There is nothing from ITIL that says that CAB meetings are only to be conducted once a week (If you find that somewhere, please let me know in the comments below).

Isn’t a daily stand up meeting functionally similar to a CAB meeting?

Doesn’t a task board or Kanban function like what ITIL would call a “change schedule”?

Good Change Management starts at the top

Change management is not just an “IT issue”.

Regardless of the methodology, no amount of velocity, flow, visualization, agility, or efficiency improvements can help without having strong leadership from senior managers.  Senior managers must develop and communicate the vision for the organization.  Goals and objectives must be clearly defined to provide the broad, overarching guidance for the company. For change management to be effective, everyone must know what is important to the business.

Senior management must seek out and break down organizational siloes. So many change management issues are cause by people refusing to collaborate.  For change management to be effective, everyone must be involved and collaborate.

IT must be part of, not separate from, corporate governance.  No differently than any other part of an organization, there must be a plan for managing the demand on IT that will result from business goals and objectives, as IT is neither an infinite or an inexpensive resource.  There must be an objective evaluation of organizational capacity – how much can be done given the resources within an organization.  Just trying to drive “more work, but faster” through an organization with insufficient capacity to meet demand is futile.

Having the above three things in place will enable change management.  But IT then must execute. Having a modern CAB is critical for that execution.

The Modern CAB

Regardless of framework or methodology, the modern CAB must have the following attributes:

  • All work must be visible – everyone must be able to view what work is being done and the demand being placed on the IT organization
  • Team members must be empowered and self-governing – this is one area where strong management support is critical.  But then those doing the work must take personal accountability for changes being done right the first time.
  • The authority for implementing a change must be delegated as close as possible to those making the change.  This means having clearly defined evaluation criteria, and identifying who approves what kinds of changes.
  • The CAB must be inclusive, with appropriate representation from all involved – not just developers or IT operations, but also colleagues outside of IT.  In some cases, this means getting suppliers involved too.   But most of all, the right people are involved at the right time.
  • Trust – When people who work together trust one another, it enables an atmosphere of collaboration instead of blame.

The relevance of IT is at stake.  IT must work as a single team.   It’s time for the modern CAB.

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Photo credit:

[1] ITIL® is a registered trademark of AXELOS Limited.

[2] From , retrieved 6/3/2017.

Share twitterlinkedinmail

6 thoughts on “The CAB is Dead. Long Live the CAB.”

  1. Doug – nice job sir. Nice to see the concept of enterprise service management through the use of complementary practices, methods and frameworks covered so nicely. If there is hybrid IT, why wouldn’t there be hybrid service management. the recognition of knowing the intersection of where things are similar and different is key.

    1. Hello Keith – thanks for reading the blog and for your kind words. Indeed, we are not living in a “one-size-fits-all” ITSM world (perhaps we never were living in such a world!) – and applying the right solution to the right challenge is critical for modern service management.

  2. Nice article and subjects for discussion. I part of a strong project culture. Where we have a great corporation with the Business. Project Steering committees where Business and IT are participating handles Business- and IT-questions related the project. IT-Committee where Business and IT are represented as well handles Business and IT issues and plans. In my perspective the main purpose with CAB is of more technical character, and it would not be relevant for Business to participate.

    1. Thank you for sharing your experiences Dorte. In my opinion, there is no one right way of managing and conducting a CAB, so long as business and IT are having the appropriate conversations at the appropriate times. From your response, it seems like you and your organization have found a way to ensure that the business and IT are having these conversations in the form of project committees.

  3. I also enjoyed the article. My organization has condensed the CAB process from static twice-weekly meetings to something more flexible using SeeviceNOW’s approval process coupled with wide communication using Slack channels for upcoming changes. Anything still ambiguous or potential impacts are discussed with one-off CABS. The condensed CAB process still evaluates the macro element of change where underlying infrastructure changes may prove impactful to application/service related changes; something often overlooked by dev teams.

    1. Thanks Craig for your comments. The concept of a CAB is not a bad thing, but unfortunately, many organizations have dumped every RfC into a single CAB – which was never the intent. It appears that your organization has “adopted and adapted” the concept to find success within your organization.

Leave a Reply

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