Why your change process is too slow

The change process can be long and tedious, slowing down your organization. How can you make it more agile? By reinventing the CAB (Change Advisory Board). Here’s how.

The problem: the CAB is slowing down your organization

We all know it: the CAB is a bit of a problem.

In theory, it’s a great way to control changes in your organization. In practice, it slows down your change approval process. Big time.

There are plenty of organizations where processing requests takes weeks, or even months. Such as this organization that at any time had a backlog of about 180 change requests and where even the simplest of changes could take months to process.

In a world where agility and adaptability have become vital for IT organizations, this is unacceptable. But how can you speed up the change approval process without losing control?

It’s time to re-invent your CAB and authorization process. Here’s what’s wrong with your CAB:

Change Process

Mindset change: not all changes should be evaluated by your CAB

Your CAB probably evaluates all requests for non-standard changes – according to ITIL guidelines. This is not sustainable and you know it.

In most organizations, there are way more change requests than any CAB can handle in their CAB meetings. During such meetings, it’s impossible to discuss all requests in detail – but of course, you shouldn’t strive for this anyway. Most requests have relatively low impact and don’t need a board of six to eight people evaluating them.

You have to find a way to separate the wheat from the chaff. You need to determine which change requests are worth the time and attention of your CAB members, and which aren’t. This might sound like a catch-22, because how do you estimate the impact of a change before you’ve made an impact analysis?

Here’s how.

Has your change process become overly complicated? This is how to simplify it. >>

The solution: introduce a Quick Impact Score

We propose a Quick Impact Score: a slimmed down version of an impact analysis for non-standard changes. The goal is to determine if a change request should be approved, and if so, by whom.

This is how it works.

1. Pick your impact criteria

First, you define some criteria to help you score the impact of a change request. It’s up to you which criteria you use, preferably no more than 5. The combination of the following factors give a pretty good indication of the expected impact of a change:

Number of affected customers: how many people will be affected by the change when something goes wrong? The higher the number, the higher the impact.
Costs: what costs would be involved to implement the change? The higher the costs, the higher the impact.
Number of agents involved: how many agents would be involved in realizing the change? The more agents and parties involved, the higher the impact.
Security: what security risks would this change entail? If the change could pose a security risk, it’s pretty likely you’re dealing with a high-impact change.
Laws & regulations: would the change in any way affect your compliance to rules & regulations? If the answer’s yes, the change request is probably high-impact.

2. Define the impact per criteria

For each of these criteria, determine a bandwidth for low, medium, and high impact.

For ‘number of affected customers’ you could distinguish the following; one person or a single team as low, a business unit as medium, and the entire organization as high-impact. Do the same for the other criteria.

When you’re assessing a change request based on these criteria, the total impact score will be decided by the highest score.

3. Determine an authorizer for each impact score

Your next step is to decide who will authorize low, medium, and high-impact change requests. You’re free to design this any which way you want, but in any case, you want to balance quality control with speed of decision-making. The trick is to involve only the necessary individuals.

Here’s how you could handle change request approval:

Low-impact: no approval needed, request is ready to be processed by the relevant agent. This is typically the case for uncomplicated changes.
Medium-impact: approval needed by a person. You could delegate this to a Change manager, but it can also be the IT Manager or another process manager. Appoint someone who operates on a tactical level and who’s familiar with the type of changes your team handles.
High-impact: approval needed by CAB. For these change requests, it’s business as usual.

Usually, about 80 percent of all requests are estimated as having low impact, and 10 to 15 percent as having medium impact. This means that the CAB would have to process only 5 to 10 percent of the change requests they’re currently handling. Let that sink in for a moment: your CAB would have 5 to 10 percent of the workload they have now.

Now you have everything you need to do a Quick Impact Score for your change request. Let’s take this process for a test run.

How to assess the impact of a change request

Say you want to update a free application such as Notepad++ for the entire organization. This can be done by a single application manager in less than a day, and doesn’t pose any security or compliancy issues. So - what does its Quick Impact Score look like?

1. Assess the change request based on your criteria

You assess the criteria as follows:

Number of affected customers: all employees => high impact
Costs: free => low impact
Number of agents involved: 1 => low impact
Security: no security risks involved => low impact
Laws & regulations: not applicable

2. The highest score is your impact score

When reviewing the total Quick Impact Score, the impact score of a change request is determined by the highest value – not by an average. In this example, all impact scores are low, except for ‘number of affected customers’, which is high-impact. This means the impact score for this entire change request is high.

3. See if you can lower the impact of your change request

When you have a medium or high-impact change request, the question is: is there anything you can do to lower the impact score?

In the case of updating Notepad++, see if you can decrease the number of customers affected. Perhaps by performing a roll-out outside of your service windows. Or by first doing a roll-out in a small test group. If this is successful, you lower the impact of updating the app for the rest of the organization as well.

How to convince CAB members to give up some control

This Quick Impact Score may raise some objections.

One of the arguments may look like this: “What you propose makes sense, but I don’t think it will work in my organization.” Usually, the underlying problem is that it means CAB members will have to give up control, and most organizations don’t see this happening any time soon.

This argument is understandable. Reviewing every change request with a group of representatives from all kinds of departments is indeed a way to control the risk of proposed changes in functionality or infrastructure. We’re not proposing to get rid of the CAB – it has and will continue to have an important function in your Change process.

But think about this: does the benefit of preventing potential (minor) risks outweigh the disadvantages your current processes has? The time spent by CAB members? The – sometimes ridiculously – long duration of processing requests? The resulting lack of organizational agility? No, it doesn’t.

For many changes, the risks in processing changes is practically zero. Some CABs spend their time evaluating whether to add a field to a certain piece of software. This should be none of their concern.

Yes, moving towards Quick Impact Scores means CAB members have to give up some control or influence about many of the changes. But that’s worth it: your organization will gain speed, agility, and efficiency. And most CAB members would much rather spend their energy on efforts that add more value to the organization instead of spending 2 hours a week reviewing every single change request.

Working towards a more agile CAB

If you truly want to improve the agility and speed of your change process, you have no other option than to revise the way your CAB works. What if a CAB member objects? Tell them how it frees up time to use their talents in another way, enabling them to have an even bigger impact on the organization than they do now.

More on Agile Service Management

Want more inspiration about how to make your service management more agile? Then the following might be relevant for you:

To dive deeper into Agile Service Management, check out our free e-book with a guide to bring back flexibility, speed and customer focus to your IT team.

Why your change process is too slow – and how to fix it

Stay up to date

Wouter Geertsma