Talking Point: When should you have CAB in ITIL Change Management Process

When should the CAB appear in the ITIL Change Management process?

This topic has been tossed and played around without any consensus. Remember that we are referring to the ITIL service management framework – and it states that the CAB is the first touch point for the change management team for any change. When an RFC gets raised in the system with all the necessary plans and details, the change manager is required to call for a CAB gathering to mull over it.

In the CAB, you have all the stakeholders and experts and they decide whether the change has merit and whether it could move forward for building and testing.

When the test results are favorable, the change comes back to change management for the authorization of the change to go ahead as per the schedule.

At a very high level, this is what ITIL V3 proposes. Remember that ITIL is non-prescriptive, so whatever they put in are recommendations and not must-dos. They expect service organizations to customize the process to their needs (and maturity).

I have had interactions with fellow management consultants who propose that the CAB is perhaps the final touchpoint for a change. According to them, the RFC must be raised with all the test results, and all data on hand – to enable the CAB to make a fair decision.

Let’s discuss the two views.

I lean towards the ITIL recommendation that the CAB must come right at the beginning, and I will state my reasons after I break down how CAB at the end is counter productive.

Let’s say you solution a project design, build and test it. Everything goes according to the plan. And then you decide to take it CAB. The CAB feels that the change presents a solution that is not in line with the organization’s standards and decide to apply the brakes and shove it into the cold storage. The effort that has gone into project initiation, design, build, tests, management and coordination is wasted. This happens all the time – most projects don’t see the light of day, thanks to change management (CAB specifically).

Suppose the CAB was held at the start, even if the change gets shelved, minimum efforts would have been lost (initiation and solutioning). At least the efforts that have gone into building and testing would have been leveraged elsewhere.

Let’s say that the CAB recommends some aspects of the project to be modified. In the CAB-last case, building and testing efforts are duplicated – and thus wasted. However, in the CAB-first case, while the building and testing efforts are saved, additional effort will go into re-solutioning. In comparison, CAB-first, offers a better percentage of effort saving than CAB-last.

I am sure there are more reasons than I have listed for the CAB to appear at the beginning. Perhaps you could bring it out? Where does your change management call for CAB? What do you think about this talking point? Where do you stand?

ITIL is based on good practices from the IT services industry. There is always a good reason for the ITIL proposed flow and activities. In my experience, following the framework to the tee (with some customization, of course) has given me optimum results.