ITIL Methodology advises that every RFC (Request For Change) be run through the CAB (Change Advisory Board).
What’s that all about, and why ? Read on !
The purpose of the CAB is to assess the impact of this change (the CAB is supposed to have a clear vision of the “big picture” of the IT / Business relationship) and to give a go / no-go answer.
This, of course, is supposed to prevent multiple changes that might collide. For example applying a security fix to close a security breach might stop an application from working, so finding out a solution to make this application work with the patch first might be a good idea.
In case the CAB give a go for this change, it still has to fit in the FSC (Forward Schedule of Changes) which is, as the name implies, a planning to ensure changes implementation won’t collide in each of their time frames. It might be a good idea to keep a bit of time in between changes which might overlap, to avoid unexpected side effects.
The RFC which is submitted to the CAB is supposed to contain related information so that an appropriate decision can be taken. For example all the items which will be impacted by the change, the steps of the operation, how long it will take, if there will be service disruption, and so on. And of course, as no IT operation always happen as planned, the RFC must include a back out plan to go back to the initial situation should the implementation of the RFC fail.
This might seem as a lot of useless work, but this is to prevent side effects and minimize service disruption. After all, ITIL methodology is all about IT giving the best service to the Business…