Why ITIL CAB’s do not work as expected
29/03/2012 7 Comments
ITIL (Information Technology Infrastructure Library) does work. It works very well and is becoming more and more widely adopted, but does not always work the way that management thinks it works.
The basic premise of ITIL is to put structure and process around the business of running IT. It is a collection of guiding principles which, if appropriately adopted into a company will help run the IT function in a reasonable process-driven fashion. It’s largely common sense, which helps.
However, after lots of experience with all of the different aspects of ITIL I have decided that it doesn’t really work the way management think it does. This is especially relevant to Change Management.
The premise behind Change Management is that technical staff are prevented from making non-Standard changes to the IT systems without prior authorisation from all relevant stakeholders.
Where this falls down is 2 fold.
– The definition of Standard change needs to be very carefully identified, documented and locked-down. It never is, leading to techies making personal decision about what constitutes standard change. This definition is always enthusiastically elastic, until something snaps when it will become frustratingly draconian (for a while).
– The stakeholders rarely understand the nature and true impact and risk of the changes taking place, so the CAB must accept the opinion of the techie (see above). The net result of a Change Advisory Board (CAB) is to authorise the technical staff to make change whilst putting the burden of responsibility for the change onto the management. Not the techie. If the changes goes wrong, then it is fault of the approving manager for not assessing the risk correctly, or for approving the change to take place at the wrong time or in the wrong way. However, the techie gets off scott free in all of this.
As long as the process is followed, we can get away with murder.
Neil Chandler's DB Blog 
Yes. When the process lays all responsibility for failures on the approving manager, all it takes is one failure to stop manager ever approving subsequent changes – for fear of further failures. They’ll only approve the change if the business jumps up and down and demands that the change MUST go through. Which leads to software maintainers releasing changes by stealth – e.g. by sneaking their changes (e.g. code refactoring, performance improvements, etc.) into the scope of other projects.
LikeLike
The onus is on the management to understand the change…
And you’re right, it can lead to change by stealth which is precisely what we are trying to avoid. D’oh!
LikeLike
I agree with you. One thing that always concerned me about the CAB and change coordinators was their comprehension levels of the issues at hand. One place had change mgmt people coming from the customer service center – yes some technical knowhow but not of the right type to make an educated decision. Not their fault – senior management’s fault because of cost.
LikeLike
It is the modern “by checkbox” mentality, applies to everything.
Does the checklist say we’re safe? Then yes, we must be safe.
Follow the checklist.
LikeLike
You’re right. Many Managers are not Managers, with decision-making ability. They are process enforcers, applying rules dreamt-up by “consultants” 🙂
LikeLike
I realise this is an old post with old comments, but what sensible alternative is there?
Hardcore techs do not want to sit on a CAB, and are also often not apparently able to evaluate risk effectively (objectively).
LikeLike
If the approval process involves correctly assessing the risk then it would be great. However, the technical level of understanding exhibited by many CAB members (in my experience – I’ve sat on CABs at half a dozen companies) is barely sufficient to qualify them to boot their own laptop, never mind understand a complex implementation. They have no chance of understanding whether, for example, the back-out process will work.
The role of the CAB can only really be limited to asking basic questions, ensuring the techies have at least considered what could go wrong, and making sure we are coordinating and scheduling multiple changes with safety. Too many firms think the CAB is validating the technical change.
LikeLike