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

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

- in ITSM and ITIL
1283
2

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.

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

ITIL proposes CAB should be the first touchpoint for the change management team. Some management consultants believe that CAB should perhaps come at the end, post the test results are available. Abhinav Kaiser stands by the ITIL framework in this regard and reasons out the positives with having CAB at the beginning.

Summary
ITIL proposes CAB should be the first touchpoint for the change management team. Some management consultants believe that CAB should perhaps come at the end, post the test results are available. Abhinav Kaiser stands by the ITIL framework in this regard and reasons out the positives with having CAB at the beginning.
0 %
CAB first or CAB last?
User Rating : 0 (0 votes)

About the author

Abhinav Kaiser is an author and a management consultant. He has authored Become ITIL Foundation Certified in 7 Days and Workshop in a Box: Communication for IT Professionals. He works as a consulting manager for a top consulting firm. He advises businesses, organizations and enterprises in the areas of DevOps, IT service management and agile project management frameworks. Social Media : Facebook | LinkedIn | Twitter | Google Plus

2 Comments

  1. Excellent article, I like the way you break down the solution so that even a layman can understand.
    I have seen your few videos as well and I very happy with content and explanation.
    Thanks and keep us educated.

    Can you post more articles and videos with real life IT scenarios mainly involving Incident, problem and change

  2. Thanks Ravindra! I will definitely do it… If you have any specific questions, let me, happy to help.

Leave a Reply

Your email address will not be published. Required fields are marked *



You may also like

Asset Database (ADB) and Configuration Management Database (CMDB) – Should they be Merged?

I got a proposition from one of my