One CAB to rule them all

Once again I find myself providing ‘practical’ advise by explaining that ITIL is not a rulebook that needs to be (mindlessly) followed as this will invariable lead to unsatisfactory outcomes (which then often are blamed on ITIL).

This is pretty much my key message in ITIL Foundations courses, but as I am doing an RCV (Release, Control & Validation) course this week, I thought I’d apply it to the Change Management theory.

I love Change Management and I think it is one of the key processes (after all, if you cannot manage your changes, what chance do you have in maintaining any semblance of control?). At the same time I have seen many organisations fall into the trap of implementing a dogmatic ITIL-based Change Management process, only to see it become a bureaucratic bottleneck. The demise of this not only leads to mistrust in any other ITIL process (paperwork, too formal, …) but often leaves a situation which is more disorganised and 'out-of-control' than it was prior to the ITIL implementation attempt.

First is the critical understanding that absolutely EVERYTHING can be classified as a change (the addition, modification or removal or any supported …). This because absolutely anything can threaten the service\value\business … from minimal, routine patches to big new systems & applications. But this doesn’t mean that every change is equal and I believe on the keys to Change Management is a good classification system, differentiating between various changes.

The ITIL theory gives us already normal, emergency (for when the ‘normal’ process can’t be followed) and standard (for repetitive changes for which the ‘normal’ process would be overkill). Good sound advice and in particular the ‘standard changes’ save Change Management from becoming a bottleneck (but more about that in another blog, another time).

Within the ’normal’ category ITIL does mention a further differentiation (significant, minor, medium, …) but kind of ‘heaps it together’ and sends all the normal changes to the CAB. Aah, the Change Advisory Board .. an often misunderstood concept.

First the advisory part: the CAB doesn’t actually authorise the change, that is done by the Change Authority. Of course the CAB can be the Change Authority, but it could be someone else, or another committee as interestingly enough ITIL allows a Change of be authorised by a group of people (where is the accountability in that?). Often in reality you’ll find the CAB actually approving the change, and if not the CAB-as-a-whole than one or two individual members of the CAB.

So, in the CAB we find anyone who’s got anything useful to say in terms of the advice of approving the change or not: developers, operational staff, customers, users, contract focused people … anyone. Well, not everyone\anyone as before the CAB an assessment should have taken place covering some of the angles. Nevertheless the CAB becomes an eclectic bunch of people who are supposed to meet regularly.

We all know how well flexibility (anyone who’s got anything relevant to advice with regards to a specific change) goes together with regularity (weekly CAB meetings). Thus many organisations will forgo one or the other, mostly choosing to have regular (weekly) CAB meetings with a wide-variety of people present.

The risk here is two-fold: firstly of course that the relevant people are not here. The consequence of this is that even after the CAB has reached a verdict these people will need to be involved and sometimes change the discussion 'down-the-track' (or just repeat it, wasting time). Worse: not involving those people can lead to a bad decision and ultimately an unsuccessful change.

But more common would be to have ‘too many’ people in the CAB, including all the relevant people but also several ‘irrelevant’ ones. For these the CAB meeting might become a tad tedious & boring and they may not show up the next time. Now be mindful that just because someone is not relevant to one change, they can still be essential for the next (so you don’t want them to ‘turn off’)!

How to reconcile this flexibility with regularity then? I don’t think I have THE answer, but it starts with realising that there is no one CAB to rule them all. The CAB is relevant to the specific change and thus different CABs should be formed to deal with the different type of change (hence my previous ramble on ITIL sub-categories for normal changes).

The 7-Rs can help, but in general it is a matter of assessing each change on its business impact, technical impact risk and costs (or ROI). Based on whether each of these assessment-dimensions is big or small the change can be categorised as big or small, and then further assessed by a big or small CAB (I often refer to a big change to be advised by a big committee and a small change by a small person (less than 5 foot).

Another useful approach is to split technical and more business\financial\contractual advice. The people involved in either are often not interested in the other and by letting them all loose in a single CAB(-meeting) it is bound to either become a highly technical discussion, or one about fiscal prudency.

In one organisation I’ve worked with, they have created a TAG or Technical Advisory Group. Here all the technical aspects of a change will be assessed first (development, transition and operation) before an advice is passed on to the actual CAB, which contains people with more a view on business reason, contractual complication, financial viability etc. For small changes (low cost, no business impact etc.) the TAG even has the ability to directly authorise the change, without the need for the CAB. The bigger the change, the bigger the CAB (either more or more important people).

It is not perfect, but it certainly works better than the one CAB option. In one organisation there were even different CABs for different business units (which each worked with different, highly specialised and frequently changing systems\applications). An overarching CAB dealt with changes that impact multiple business unit, or where a CAB couldn’t make a decision.

Ultimately I think ITIL has three steps here within Change Management: assess - advice – authorise (funnily enough, even though there is a Change ADVISORY Board, ITIL doesn’t make this activity very clear in the process diagrams). Within these steps anyone who’s got anything to say should have the ability (or the requirement) to do so … or forever hold their breath (and accept that & how the change is approved without their input).

The CAB is a big part in that, but there are other way to make this more practical (TAG, assessment forms\checklists\reports, different CABs for different changes, electronic approval flow, …). Whatever works within your organisation, for your (different) changes!

the ITIL Zealot
February 2013