How to Stop Sending Every Flipping RfC to a CAB

If your IT organization funnels every Request for Change (RfC) to a Change Advisory Board (CAB) for implementation approval, then you’re doing change management wrong.

If this is happening in your IT organization, do you even know why you’re doing that? What is the real value of sending every RfC to the CAB? I would agree that some RfCs do require review and advice from a CAB – but every RfC? Or even most RfCs? I think not.

In my experience, there are four reasons why organizations send all or the majority of RfCs to a CAB:

1. The change management process is poorly designed.
2. The business requirement for making the change (“what is the target result?”) is not clear.
3. The scope of the RfC is not clear.
4. There are some in IT more concerned with going through the motions than doing good work.

A well-designed change management process should facilitate, but not overly control, the implementation of changes. An effective change management processes removes as much friction as possible by providing clarity regarding how changes will be managed. At the same time, a good change management process strikes the right balance between protecting the managed environment from a malformed change and making changes to that environment.

If change management is well-defined and well-executed, only a select few RfCs (with the emphasis on ‘few’) should be brought before a CAB. Ever.

Why Your CAB Doesn’t Work

Why are many organizations frustrated with their change management process? Because how a CAB is positioned doesn’t work. The CAB has been positioned as an obstacle or gatekeeper and not as an enabler. That’s why, in many organizations, the CAB is set up for failure.

What are some of the symptoms of a CAB that has been set up for failure?

• Formal RfC evaluation criteria has likely not been defined. If it has been defined, it’s not well documented or published.
• RfCs are poorly written. The purpose of making the change is not clear, it’s not clear what resources are needed, or what known dependencies exist.
• Every RfC, regardless of scope, is sent to a CAB for approval for implementation. Not only does this demonstrate a lack of understanding of the purpose of a CAB, it’s also indicative of poor process design.
• RfCs are frequently submitted at the last minute and are subsequently bulldozed through the process. This indicates a lack of management support. This behavior also guts the change management process. It bypasses any feasibility review and ignores any impact on changes already planned and scheduled for implementation.
• Too many “emergency” changes. Unless there is an error in the environment that is impacting a vital business function, or the business is facing imminent harm unless some action is taken, this is just blatant “lack of planning.” Again, in the absence of a well-defined process and strong management support, this behavior is tolerated.
• The CAB is made up of disinterested or unqualified members.
  I once worked with an organization that conducted CAB meetings twice a week from a large conference room. There were a number of attendees in the room, as well as a number of attendees that joined via conference call. The change manager diligently read aloud the title of each RfC on the agenda, followed by asking “any concerns?” Rarely, if ever, were there any “concerns” and the request was “rubberstamped.” Even more concerning, nearly everyone in the conference room was doing something else – checking email, texting, talking with their neighbor. I can only imagine what was happening on the other end of the conference call. What value did the CAB meeting provide? (By the way, this organization had a high change failure rate. Go figure.)

Want to know the reason why your CAB doesn’t work? Poor process design and a lack of management support.

Want to fix that?

Here’s how:

1. Define a change authorization model
2. Right-size your RfCs

Introducing the Change Authorization Model

Does your current change management process define the authorization model? What? You’ve not heard of the authorization model? Go have a look – it’s discussed in the ITIL® Service Transition book on page 78. (I will wait.)

The authorization model defines who authorizes or approves what type of changes. The level at which change is authorized “rests where accountability for accepting risk and remediation exists.”[1]

Change management should not be a ‘throw it over the wall to IT and wait for something to happen (and complain when it doesn’t)’ scenario. Implementing a change is a business decision – and identifying and enabling the right people to make good decisions is critical. The change authorization model is a way to ensure that the right people can make good decisions.

Defining the change authority requires a formal definition of RfC evaluation criteria. Criteria such as cost, resource requirements, risk, scope, cost of delay, and other factors should be identified and defined as part of the criteria. Again, this is not a decision for IT alone – this is a business decision, so business colleagues must be involved in defining evaluation criteria.

Once the change authorization model is defined, everyone in the organization can understand not only how an RfC will be evaluated, but also who will be providing authorization. When an RfC meets the defined evaluation criteria for a specified level, then those individuals identified as being accountable for that level attend the CAB meeting that reviews that RfC. Defining the change authority also resolves a long-standing question for many change managers – ‘what business colleagues should be involved?’ The change authority helps answer that question.

Right-Size Your RfCs

So, how do you stop sending every flipping RfC to the CAB?

Simple. Stop sending every RfC to the CAB. Start sending only the right RfCs to the CAB.

I’ve long thought that the overarching goals for change management are to move the authority for change implementation as close as possible to those doing the work, while at the same time, maintain an appropriate degree of governance of changes.

By limiting the scope of an RfC to the minimally viable unit of work improves the manageability of the RfC – it becomes easier to design, build, test, and implement a change – because there is less to do. Because there is less to do, limiting the scope of the RfC also reduces the amount of risk associated with change.

If the scope is smaller and risk is minimal (and you’ve defined the change authorization model appropriately), the RfC will meet the defined evaluation criteria for a lower level of the change authority – ideally, those that are doing the work.

Stop Sending All RfCs to the CAB

Designing and implementing the two improvements I just explained to your change management process not only improves the responsiveness of the process, but it also helps position a CAB for success.

Here are a few other things to do to further improve your change management process and get the best value of a CAB:

• Define change models. Many changes are routine and are implemented frequently. Defining and using change models not only ensures execution consistency, but it’s a first step toward change automation.
• Leverage pair programming. This is a fantastic DevOps concept that drives higher quality code, resulting in higher success in implementing changes.
• Define the service portfolio. A service portfolio provides information regarding services and current investments and commitments in IT that can be used as input to change authorization decisions.

Enable your change management process to actually facilitate implementing, not preventing, changes.  Defining the change authority is an often-overlooked, but critical factor for the success of an effective change management process.

[1] ITIL Service Transition, p 78.