Change advisory board (CAB)

The typical IT change enablement process starts when an individual, process, or business unit raises a change ticket. The change ticket gathers information such as the configuration item associated with the change, the reason for the change, the requester's identity, the change type, and costs. The ticket is then reviewed by a change authority who assesses the need for the change. They may request more information about the change and its business practicality and reject the request if it doesn't seem to be of much value. The review involves the evaluation of the impact (on infrastructure, business, and other services), anticipated risk, financial constraints, and benefits of the IT services; the review is thorough because it is imperative that there is no disruption to business operations.

Once the change ticket is approved, the IT change is implemented by the appropriate technical teams who build, test, and deploy the change. If the change is to fail, or there is going to be downtime, a backup plan must be used. When the change is built and tested, the change manager gets notified. The change manager, along with the release management team, uses a change calendar and announcement/notification features, and schedules and plans the deployment of the change. Upon implementation of the change, the entire change process is reviewed and documented.

The evaluation of the IT change and its implementation process is performed by a select team of highly skilled and experienced people. This team is called the CAB, and it is an important component in the change enablement process. Apart from subject-matter experts, this team can also be comprised of service desk analysts, application managers, senior engineers, and operations managers.

In brief, the CAB is a group of dedicated individuals from various facets of a business who assess the change from the ticket initiation stage to the post-implementation stage, providing various perspectives, recommendations, and course corrections when needed.

Understand the importance of a change advisory board (CAB) and learn how you can manage them effectively in a hybrid environment.

• Assess change requests from both a technical and a business perspective.
• Schedule and prioritize change requests.
• Calculate the risks associated with the change and present stakeholders with evidence and supporting documentation on why the risk is or isn't worth taking, including the benefits of the change or the reasons for rejecting it.
• Propose risk mitigation plans.
• Monitor the progress of a change and provide feedback.
• Maintain standards for changes.
• Guide the change manager in decision-making.
• Communicate by creating extensive documentation of the evaluation of changes irrespective of them being a success, failure, or pending.
• Take responsibility for continuous improvement initiatives in the change enablement process.
• Make sure the entire organization is aware of and adapts to new changes.

Some of the risk and impact analysis done by the CAB is based on questions such as: How will subsequent IT services be affected? Will the performance of IT services increase and thereby add business value, such as an increase in end-user satisfaction? Can the business allocate the financial resources that this change will demand? Are the required resources available? Will the change impact data security and compliance?

Security threats and power outages are examples of emergency changes, changes that pose high risk if not promptly attended to. The main difference between a CAB and an ECAB is that the ECAB assists the change manager in speeding up the emergency change process so that no unacceptable delays occur.

The ECAB only consists of people who have the knowledge and skills to implement the change; rarely does it comprise top-level executives. This eliminates some of the constraints that would be considered during the implementation of a normal change. The ECAB solely focuses on solving the issue and implementing the emergency change as soon as possible to prevent more damage from occurring. Before deployment, the emergency change gets only basic testing done to save time. Therefore, most of the time, an emergency change is re-evaluated after the implementation to make corrections because untested changes may cause even more damage in the long run.

The ECAB works swiftly and sometimes, when absolutely necessary, waives the extensive testing processes, instead making on-the-fly decisions that have considered the trade-off between risk and reward.

"A change ticket is implemented only if the CAB approves it."

The primary responsibility of the CAB is to provide recommendations and guide the change manager in decision-making. The change manager is the one who has complete authority to green-light or reject a change.

"Every change must go to the CAB."

Not every change has to go to the CAB for review. For instance, OS upgrades or life cycle replacements of devices such as PCs, workstations, printers, and servers do not need their change tickets assessed. As a best practice, only particular necessary change tickets need to go to the CAB. CAB approvals can also be predefined. While configuring a change template or workflow, certain changes can skip the CAB process by preapproving the change.

"The CAB is a rigid, immutable institute."

Numerous CAB teams can be created and customized based on the needs of the IT changes that are created. CAB members are chosen based on the knowledge and expertise required for the execution of a particular change. CAB members can be business relationship managers, third-party members, customers, and end users as well if they give value to the decisions being made.

• Determine specific CAB teams for particular change request categories. Predetermining CAB teams allows the team to have members with the precise skill set needed for smooth implementation of a change. CAB teams can also be created based on the level of risk involved in the change requests.
• For a successful change enablement process, define change progress states and configure or customize the statuses for each stage. For example: Approval pending. When a change's status gets updated, an automated email or SMS notification can be sent to the respective stakeholders. For instance, when the planning stage of an IT change is completed, the status goes from Planning in progress to Approval pending. When the status gets updated to Approval pending, the CAB members are notified about their tasks. This information helps the change manager and other stakeholders see the progress of an IT change at any time.
• Use a change calendar to keep track of all things related to a change. For instance, the calendar can give details about when a particular service will be down for maintenance and when it will be restored. Whereas a change timeline allows all stakeholders to know which phase of the change is being carried out at that particular time, this feature allows the CAB members to keep track of the IT change's progress at all given times.
• Work closely with other IT service management (ITSM) processes such as the CMDB and release and deployment management. The integrated ITSM processes help the CAB team make quick, comprehensive decisions using all the information they would need at their disposal. The CAB team also makes recommendations on how other processes such as release management can plan for an effective change implementation. The right ITSM tool enables organizations to initiate a new change request from problems or incident tickets. As change enablement focuses on transitioning new initiatives from development into operations, release management ensures that the change flows into pre-production environments, ensuring successful deployment into the production IT environment.
• Use out-of-the-box features in ITSM tools to analyze the opened, approved, or rejected change tickets and execute various other change enablement activities. ITSM tools provide capabilities related to the CAB process also. For example, with a change calendar, organizations can visualize, organize, and manage changes by week, month, or year.
• Not all change implementations can go as smoothly as planned. To prevent disruptions, the change manager, with the CAB team's guidance, must put forth a rollout plan, backout plan, and check list that has all the items required for the plan to succeed, and assess and prevent downtime.
• Using an ITSM tool, organizations can preconfigure particular CAB teams for each change type. This way, when ready for approval, change tickets are automatically sent to the right CAB team based on the change type defined in the ticket requesting the change.
• With the help of built-in reporting, organizations can use an ITSM tool to draw up reports based on the priority, urgency, impact, associated incidents, and associated problem count of changes. These reports can help the CAB team guide change managers on prioritizing and scheduling changes.
• By tracking the right KPIs, even after implementation, CAB teams and other stakeholders can effortlessly derive insights about the effectiveness of a rolled-out change.
• By tracking all change-related activities and their progress, an ITSM tool eliminates the tedious documentation work done by the CAB team.

With the right ITSM tool, not only can organizations leverage all the features listed above but they can make the overall process of implementing an IT change effortless. Most CAB activities can be preordained through automation and various out-of-the-box capabilities in an ITSM tool. This automation allows CAB members to not waste time on menial tasks; instead, they can focus on tasks that require their specialized knowledge and skills. An ITSM tool like ServiceDesk Plus allows organizations to effortlessly control all phases of an IT change and collaborate with other ITSM processes to execute a holistic, risk-free IT change.