Technology is best described by the adage from Greek philosopher Heraclitus: The only constant thing is change. In this age of digital transformation, customers and competitors can find solutions and alternatives at the touch of a button. This speed means that service providers stay ahead only by embracing and executing change quickly, yet maintaining sufficient control to manage risk.
In change management and execution, there are two key factors to your company’s success: your technology and your decision-making processes. We’ll explore two structures, or bodies, that focus on change-related decision making—the Change Control Board and the Change Advisory Board. The biggest difference between these two bodies is their scope:
- The CCB primarily handles changes within projects
- The CAB covers all changes related to the service lifecycle, including emergency changes
Let’s explore in more detail what they do and how they differ. We’ve also included additional resources at the end of this article.
Change management and decision making
When it comes to management and control of changes to services and service components, one of the biggest challenges is determining who has the authority to make change decisions.
IT service management has long suffered from bureaucratic approaches and general risk aversion—which results in layers of approvals, development delays and confusion, and, ultimately, failure to deliver value to customers in an agile manner. This situation is exacerbated in companies with legacy systems and structures that prohibit the flexibility for change that digital transformation requires.
The Change Control Board and the Change Advisory Board are similar organizational structures that play vital roles in decision making. Both are comprised of teams whose role is to collectively help the organization make the right decisions of balancing need and risk of changes to technology that supports business processes, but they’re not the same.
What is a Change Control Board?
A Change Control Board (CCB), also known as the configuration control board, is a group of individuals, mostly found in software-related projects. The group is responsible for recommending or making decisions on requested changes to baselined work. These changes may affect requirements, features, code, or infrastructure.
Poor change control can significantly impact the project in terms of scope, cost, time, risk, and benefits. Therefore, it is crucial that the CCB members are sufficiently equipped with information, experience, and support necessary to make the best decisions.
Creating a Change Control Board
The CCB is created during the project’s planning process. The most successful CCBs include representatives for both the project implementer and the customer, whether they are from a single organization or different ones. In a software project, these would include management or leads from the following units:
- Program or project managers
- Product managers
- Business analysts
- Developers
- QA
- Operations
The Change Control Procedures and the Change Control Plan, established during the planning phase, will define the role of the CCB, which can range from simple recommendations to more holistic decision making. The procedures and plan documentation will also include:
- The structure and authority of the CCB, such as:
- Which levels of change require CCB approval
- Whether lower levels of change can be made by the project manager, for instance
- Whether higher levels of change must be elevated to a higher governing body, such as the board of directors
- The frequency of meeting
- The rules for decision making
- Communication methods
Best practices for CCB process
To ensure that the CCB can be effective in its reviewing and approving of proposed modifications in a strategic, organized, and coordinated way, consider adopting the following best practices:
- Diverse representation: Have a diverse set of members, including IT team members, customers, suppliers, and potentially others, depending on your situation.
- Clearly defined responsibilities: Specify clear membership roles and the authority to approve or reject changes, to ensure that the board has the agility to respond to change quickly, and that both business and technical expertise are put to best use.
- Comprehensive charter: Spell out in a written document the purpose, scope of authority, membership criteria, member responsibilities, operating procedures, and process for making decisions that the CCB will use.
- Documented decision-making process: Spell out the decision-making process up front to prevent conflict and speed the function of the CCB. Decide what constitutes a quorum, define the powers of the board’s manager, and establish what decisions need to be ratified by a higher authority.
- Effective communication: Organize the communication channels the CCB will use and set the update frequency. One member should be responsible for maintaining a single repository of up-to-date information and coordinating to keep stakeholders in the loop.
- Scope-creep management tactics: Balance change requests against project timeline and costs to keep the project on track and to stop scope creep.
How many Change Control Boards is enough?
Organizations may choose to have a single CCB handling change requests across multiple projects. For larger projects, you may want a dedicated CCB. Some projects might require multi-level CCBs. A low-level CCB could handle lower priority change requests, for instance non-customer-facing features or changes with low/no cost impact. A higher-level CCB could tackle major change requests that have significant impact on costs or customers.
What is a Change Advisory Board?
Mostly involved in decision making for deployments to IT production environments, the Change Advisory Board (CAB) is a body constituted to support the authorization of changes and to assist change management in the assessment, prioritization, and scheduling of changes.
The authority of the CAB can vary across organizations. Usually, if top leaders or C-suite executives sit in the CAB, then it has the highest authority. The organization’s change management policy will define the CAB’s constitution and its scope, which can include anything from proposals and deployments to changes to roles and documentation.
Creating a Change Advisory Board
In most organizations, the Change Manager chairs the Change Advisory Board. The CAB will have a pre-determined schedule. Depending on the typical activity in your IT department, your CAB may meet as often as twice weekly. No matter the frequency of meetings, the Change Manager should communicate the scheduled change required well in advance of meetings, so individuals on the CAB are prepared to make the best decisions.
Best practices for CAB process
For your CAB to function effectively in providing oversight and guidance, consider these best practices:
- Assess existing CAB gaps. Take a strategic look at your current CAB structure and processes to get a good idea of what is working and what needs to be improved.
- Gain support for CAB improvement or creation. Communicate with leaders in your organization and those who are involved in decision-making to capture their opinions on what could improve an existing CAB or what would contribute to successfully creating one.
- Identify the CAB owner. As with any organization, someone needs to lead operations and own the outcomes of the CAB. Make sure responsibility is clearly assigned.
- Create a standard CAB agenda. Plan a program of topics to discuss and decisions to make before each meeting. A regular agenda lets attendees know what to expect and structures meetings so you stay focused on important decisions.
- Determine the meeting cadence. Schedule regular meetings as frequently as you need, depending on the rate and kinds of changes expected. Make sure that stakeholders carve out time to devote to the CAB.
- Host CAB meetings, improve processes, and iterate. Capture feedback after every meeting so you can improve processes and agenda items, adapting to changing situations as they arise.
How a Change Advisory Board makes decisions
A Change Advisory Board typically makes decisions in three major areas, which we’ll review below:
- Standard change requests
- Emergency changes
- Previously-executed change audits
Standard change requests. At every meeting, the Change Advisory Board reviews requested changes using a standard evaluation framework. That framework should consider all dimensions of the change, including service and technical components, business and customer alignment, and compliance and risk. The CAB must also look for conflicting requests—these cases in particular require CAB members to maintain holistic, business-outcomes views that don’t favor the particular team or individual seeking the change.
Emergency changes. Occasionally, the Change Advisory Board must handle an emergency change. This might happen when your company experiences:
- A service outage (actual or potential)
- A security breach
- A compliance requirement
In these cases, an Emergency Change Advisory Board (eCAB) can be formed as a temporary subset of the routine CAB. The eCAB may include some or all individuals from the CAB, and this group will meet outside the normal schedule to review the necessary emergency change(s).
Previously-executed change audits. The CAB can also meet to review previously executed changes particularly those that were unsuccessful or unauthorized, as well as plan the forward schedule of future changes particularly with regard to projected service outage and customer/business plans.
Comparing CCB vs CAB
The Change Control Board and Change Advisory Board share a similar focus of reviewing and making decisions for change requests, though their scopes vary widely. Regardless of differences, the structure for both change bodies must be clear, effective, and efficient. Without these components, companies will fall behind competitors who make changes quickly and safely. Companies must continuously ensure the CCB and CAB succeed, and they’ll also want to prevent change-related bottlenecks, particularly when it makes sense to cascade ownership from decision teams to the teams that own solutions, such as product teams or joint technical teams.
Learn how ServiceOps can help you predict change risks using service and operational data, support cross-functional collaboration to solve problems, and automatically recommend problem resolutions.
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.
See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.
