Killing CAB, Part I: Standard Changes

Hate CAB? You’re in good company if you do. I’ve never met someone who actually likes coming to CAB. What I come across far more often is people who hate ‘CAB’, and would rather do just about anything to avoid it.Standard Changes

I’m often asked what changes have to come to CAB. It’s a trick question, of course, the real question behind the question is – how can I avoid taking changes to CAB.

So, here’s the straight up answer: All changes to the production environment are under the authority of change management, but…..

Not all changes need to come to CAB. In fact, as your change process matures, the less actual changes the CAB reviews.

Yes, I’m aware that I’ve just said (in a mathematical sense) that ultimate maturity is achieved when CAB reviews zero changes.

Deming is well known for saying that you cannot inspect quality into a (manufacturing) process – quality has to be engineered in to the overall process.

Ironic then, that the average CAB is pretty much a last-check inspection at the end of the development process.

This article is the first of three with practical ways to kill off CAB (or at least reduce the number of changes coming to CAB), while maintaining or increasing the quality of changes.

The Role of CAB

There’s nothing inherently wrong with a last-check CAB – it has value in that it catches a fair number of issues that would have caused adverse impact.

The problem with it is that it requires all changes to be CAB reviewed in order to create that value. It kind of becomes a one-size-fits-all review where all changes are given roughly the same scrutiny, and makes for marathon CAB meetings.

But as your change management program matures, CAB should be increasingly concerned with end-to-end quality of the process, and less about individual changes. The role of CAB, then, is to ensure that the quality of all changes meets the needs of the organization. The focus is on the outcomes of change management, not the process, and most definitely not the CAB itself.

As your focus shifts to the results produced by the change process, Standard Changes allows CAB to ensure a predictable level of quality of changes without having to review each one.

Standard Changes

Standard changes are one of the easiest and fastest way of reducing the number of changes coming to CAB. Let’s start with a quick description of standard changes. (See also The Difference Between Standard and Normal Changes in ITIL. )

Standard changes are changes that are done frequently, considered low risk and have been CAB reviewed and approved by the change manager.

It’s worth mentioning that standard changes are not those done so frequently that it’s impractical for them to be reviewed, and are just ignored by change management. While this may be common practice, it’s hardly a good one. All changes pose risk, and the role of change management is to effectively manage change-related risk . This isn’t possible if changes ‘fly under the radar’ to avoid CAB.

Standard changes are a win-win alternative.

With that said, every change that comes to CAB should be considered to see if it’s suitable to make into a standard change.

Should this change be a standard change?

What kinds of changes make good candidates for standard changes? How do you know?

Here’s some things to consider:

  1. Is it done frequently in daily operation?
  2. Has CAB found issues with similar change requests in the recent past?
  3. Has there been incidents or service impact from similar changes in the recent past?
  4. Is there a documented process for the requested change, and is it consistently followed? (If not; can it be documented?)
  5. Is the request associated with any critical business functions, or highly sensitive infrastructure?

Making a standard change

If a change is a good candidate for a standard change:

  1. Ensure there’s good documentation for how the standard is/will be carried out.
  2. Submit the standard change documentation to CAB as a Request for Change for review.
  3. CAB reviews the standard change process for risk and operational concerns
  4. Change manager approves (or rejects) standard change.
  5. Approved standard changes are carried out as needed in daily operation, following the approved process.

Operational Considerations

In daily operation, standard changes should:

  1. Not be submitted as RFCs
  2. Not be reviewed individually by CAB
  3. Be completed following the approved, documented process
  4. Be recorded in a way that can be reviewed by operational staff. (For incident and problem management, continual improvement, audits.)
  5. Periodically reviewed for improvements

Its important to keep in mind that standard changes remain under the domain of change management, and if incidents arise from approved standard changes, change management should take action to determine the reason(s), and if corrective action needs to be taken.

In Practice

Standard changes are an excellent way to get CAB focused on much larger, more critical changes, while maintaining appropriate control. Once the level of risk is identified and accepted in the form of a standard change, operations staff should be encouraged to use as needed. Unless/until issues arise, CAB should pay very little attention to standard changes.

If you are just getting started with formal change management, or if you have an unpopular and bureaucratic CAB, standard changes will be a welcome relief. I strongly encourage setting a goal for number or percent of standard changes, and track as a change management operational metric – the number (or percentage) of standard changes.
Photo Credit: Jason Lander via Compfight cc