The Change Advisory Board (CAB) is arguably the most widely known ITSM activity. It’s also widely misunderstood. Here’s the quick lowdown on CAB.
What is CAB?
CAB – known formally as the Change Advisory Board, is a group of people who are tasked with evaluating changes to the IT environment. It can be as simple as an email distribution list, or as formal as a Chairman-led, take-minutes, raise-your-hand-to-speak board. The culture and the business needs of the organization determines what’s appropriate.
The CAB is comprised of technical staff and key decision makers. There’s no set rules for who’s on CAB. The Change Manager ensures the right people with the right information, knowledge, and background are there to effectively review each change.
It’s not uncommon for Subject Matter Experts to be called in to help review and advise on specific Change Requests because of the nature of the Change. ( i.e. Senior Network engineer for router changes.)
‘CAB’ and ‘Change Management’ are not the same. CAB is focused exclusively on reviewing Change Requests for risk and unintended consequences, and advising the Change Manager of their findings and recommendations. Change Management is the broader capability that manages the entire process of raising, reviewing, evaluating, approving, and tracking and overseeing all changes.
What’s a Typical CAB Look Like?
CAB should be staffed with representatives from all functional areas/technical disciplines, key decision makers, and business stakeholders, as appropriate. The Change Manager organizes and runs the CAB meetings.
Typical Members:
- Senior Network Engineer
- Senior Application Development engineer
- All Operations Managers
- Service Desk
- Server/Infrastructure engineer
- Senior Security Engineer
- Information Security Officer
- Business Relationship Manager(s)
- Service Owners
- Business users
What’s the CAB do?
Let’s just get this out of the way up front – Change Advisory Board is often misunderstood to be the Change Approval/Authorization Board. It’s advisory because it’s job is to review proposed changes, and advise the Change Manager of the results of their findings.
It’s the Change Manager who ultimately approves (or rejects) Changes.
With that out of the way – here’s what the CAB does:
- Review Request for Change (RFC). Use knowledge, experience, and background to asses change for risks and unintended consequences
- Ask probing questions to fully understand the proposed change
- Evaluate proposed change for risks, and mitigation.
- Ensure that business outcomes are documented and well understood
- Schedule and prioritize changes
- Evaluate if the proposed Change will give the intended outcomes without adversely impacting the business.
- Ensure the proposed time is appropriate (doesn’t conflict with business needs, other change, or operational activities)
- Ensure technical and architectural standards are met
- Determine likelihood of unintended impacts
- Make recommendations to reduce risk, increase likely success, and minimize business impact.
- May request a more in-depth, formal Change Evaluation for a given change. CAB uses the findings of Change Evaluation to asses the Change.
What Changes have to go to CAB?
Generally, all changes to the production environment are brought to CAB for review. If there is delegated Change Authority, (which I highly recommend ~ See Five Lessons from Implementing ITSM Change Management), smaller changes may be reviewed by the delegate.
If every tiny tweak has to come to CAB for full review and approval, staff are likely to find ways to get around it.
Rightfully so.
Standard Change to the rescue! Standard Changes are well understood (generally have documented processes), and are low risk. The standard process is reviewed by CAB, and once approved, is used in daily operations to manage standard changes. (See Whats the difference between Standard and Normal Changes in ITSM.)
Whatever structure you put in place, be sure to document it, and make sure everyone understands it well.
What Authority Does CAB have?
Change Management is a control process – it’s intended to control changes to the environment. CAB is part of that process, but is not the decision maker. The Change Manager herself is ultimately accountable for approving/rejecting changes.
The Change Manager will generally follow the advice of the CAB, but can approve Changes (for many reasons) that the CAB has recommended against.
It’s best to make this clear early and often. Clarity in Ownership and Accountability is critical for a successful CAB.
What are you waiting for?
While Change Management may be more complex, CAB is pretty much CAB – as I’ve described here. Best to keep it simple and focused on quickly implementing business requested changes, while managing risks and minimizing unintended consequences.
Have a CAB? Thinking about implementing one? Let’s hear from you!
P.S. If you liked this article, you might enjoy the ITSMTransition Newsletter. Receive each new article right to your inbox! Sign up here.
If making a change requieres the development of solutions, where does the CAB should reside? Before or after development? Before or after desing?
It should be brought to CAB first to help “advise” on what solution should be developed, or more over, what sort of solutions are viable for that organization. After a plan is created for those solutions, it should be brought back for more advisory information and approved before moving forward with those changes. So as far as before or after designing, definitely before. CAB can influence exactly what the design will be, so if the design is created beforehand, CAB’s influence can push a change that causes a lot of wasted hours. Plan, Meet for CAB, Design and Implement.
I would respectfully disagree, Michael. The role of the CAB is NOT to consider whether a solution is fit for purpose or well designed or the best solution for your business; that is what an Architectural Review Board or similar is for.
A CAB is SPECIFICALLY to ensure that a change (whether or not you think it’s the best change) will not break the production environment when it is deployed. Risks it is mitigating are, for instance, an incomplete deployment process (so the change will not work and/or won’t be able to be rolled back); clashing changes (two changes in the same window that will interfere with each other); incomplete testing (so we don’t know if the deployed change will work properly within our environment) and so on. If it gets bogged down considering if the solution is the right one, then its purpose will be diluted.
I can see that a CAB can pragmatically cover off the role of an Architecture Review Board too; but you should be aware that you are doing two quite different things. Make sure that for instance you don’t get hung up on the requirements and miss the fact that you’re deploying the solution on the same night that you’re upgrading your routers, or that you’ve optimised the design but missed the dependent applications that will stop working when your new solution is deployed.
Does CAB have any role in steering the process and helping with process improvement? What level of management generally sits on CAB?
CAB role and makeup are directly related to the maturity of the process. A very reactive “disaster check” CAB has to be staffed by technical experts. These experts work together to uncover any unintended consequences. This has value to the business by averting problems. But as the CAB matures into a control process (as it’s intended), it becomes increasingly staffed with management.
If by CAB role in process improvement you mean in the Change Management process, the answer is a most certain ‘yes’. Because of it’s makeup of senior technical staff and management, CAB is generally a key source of improvement recommendation.
But you may also have meant CAB’s role in improvements in all processes, and that’s a really good question. In a mature organization, processes associated with delivering services are under change control. Changes to operational processes are proposed via RFC and reviewed by Change Management. The reason, of course, is because changes to underlying delivery process can impact services and the business processes they support.
Thanks for stopping by!
Does CAB involvement required for all below changes:
Normal (Significant Impact, Medium Urgency)
Emergency (Moderate Impact, Immediate Urgency)
Normal (Minor Impact, Medium Urgency)
Standard (Minor Impact, Low Urgency)
Thanks for stopping by, Saket.
The answer depend quite a bit on the maturity of the Change Management capability. In short, the more mature the change process is, the less direct involvement CAB/Change Management will have on individual changes.
Standard changes are a good example. The idea is that standard changes are proposed to change management in the form of a documented process for the desired standard change that addresses all the relevant points with which change would be concerned – risk, minimization of negative/unintended impact, and effective management of the change. Once reviewed by CAB and approved by Change Management, those standard changes can be performed in daily operations, as documented and approved by change management. In standard changes, change management is delegating authority for that change to operations. If problems arise, change can revoke standard change authority – as deemed appropriate in the best interest of the business.
In order for Change Management to mature, it has to become more focused on the end-to-end process of changes, and less concerned about individual changes. To move in this direction, change management should maximize the number of standard changes, develop class-type change models, and establish effective change authority delegation structure. I’ve started talking about these in my Killing CAB series (http://itsmtransition.com/2015/12/killing-cab-part-i-standard-changes/).
Emergency changes are a big challenge for many organizations. In many cases, they are used far too frequently, and often as a substitute for effective planning. I my view, Emergency changes should only come into play when there’s an established, active Major Incident, and change authority is (temporarily) delegated to the Incident Manager. In a true major incident, this level of authority is appropriate to fully manage the incident. In a manor of speaking, then, CAB is bypassed, but the lines of authority are kept clear by using delegated authority that ultimately still falls under the ultimate authority of the change manager.
More common, is for emergency changes to be run through a streamlined “emergency CAB” (or similar), that’s designed to meet the timeframe required of emergency changes.
That brings us to “normal” changes, that you’ve divided by it’s impact potential. The most common practice is to run them both through the single CAB process where they may be handled differently, but through the same cycle/process.
Here again, I’m a fan of delegated change authority, giving as much authority to lower levels as the associated risk would deem appropriate. If i were asked for a generalized opinion, i would recommend delegating your lower impact changes to lower authorities (than CAB) – closer to the operations staff who likely have a better view of risk and potential impact. Changes with “significant” impact potential would then be elevated to a higher authority. “significant risk” undoubtedly translates to risk to the business – ability to process transactions, public perception, information security and so on. Ownership for all significant business risk lies with senior management, and change management must include appropriate escalation of risks to the right authority level, keeping in mind that the risks we’re talking about here are not limited to technical risks,
One of my favorite structures for this is where delegated change approvers’ decision making authority can be taken away in the event changes they approve have adverse impact. Naturally, they are motived to make good decisions and retain their change authority, so if they are not completely convinced of a change, or they recognize that it has impact outside their decision domain, they will escalate it to a higher authority. Over time, it’s a self-optimizing process.
It’s important to note that there’s no single “right” answer to your question, and ultimately, you have to understand your organization and the business you serve to find the right solution.
Hope this helps.