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

Common sense written down

Once again I find myself ‘improvising’ this blog, pushed by my self-imposed deadline of two articles a month (I was on holiday in January, hence the ‘lapse’ then). Extra pressure this time, as I've almost breached the threshold of 500 twitter-followers so perhaps this article will add those last few and get me across the line.

The title is my current favourite description of best practice: ‘Common sense written down’. I use this in my training courses, at the beginning. Not just because I need to explain the concept of best practice in the beginning (and the justification of ITIL), but also to take away any anxiety from the students … this is just going to be ‘common sense’. In fact I go as far as sometimes proclaiming that people will not actually learn anything (new) in the course, as hopefully they already possess common sense. Then again common sense isn't all that common, and in some cases (including in parts of ITIL) doesn't actually make sense!

This came to mind when I saw a twitter-discussion recently. It was started by Rob England (@theitskeptic) and a ‘review’ of a CSC Cheat Sheet (http://www.itskeptic.org/content/how-embarrassing-csc). In here it was recommended to start ITIL ‘with a manageable list of 10-15 carefully chosen subsets of the processes’. Rob’s comment was that ‘you are gonna have all of them, like it or not’. This was followed up by Stephen Mann (@stephenmann) who wondered how many organisations do more than 10 ITIL processes, and once again Rob responded with ‘how many DON’T do all (of them)?’

I am with Rob here: common sense is already in place (in most cases, there may be an exception or two) and thus you already DO ALL processes. Using ITIL doesn't mean doing more or less than you are currently doing but you can change and formalise your existing activities to be more aligned to the ITIL recommendations, terminology etc.

The word DO is perhaps wrong here, though not as wrong as the word IMPLEMENT. I have to admit that I too have been part of ITIL implementations, but over the years I've grown to detest this description. For one as it indicates ITIL is a goal and not a means but mostly as it implies a beginning and an end (as in a project). ITIL (or more generically ITSM, service management) is continuous: you did it before you knew ITIL, you’re doing it (better) after you've written some processes and you’ll have to keep doing it after (see also CSI).

We need to once and for all understand that ITIL is DESCRIPTIVE. It describes a perfect world, greenfield, best practice organisation and none of us will ever do everything, exactly as ITIL describes it. But that it not what it is there for!

The benefit of a best practice, of common sense written down, is that it allows you to verify that the activities you are performing are aligned with this best practice\common sense. Chances are you’ll find that you may not be doing all activities (or not all the time, or not as rigorous as required) or maybe you are doing too many. Thus a best practice like ITIL can help you to become more effective and efficient, not by dogmatically adopting everything it says, but by judiciously adopting your activities & practices (yes Rob, I’m ready to start that discussion) along the described theory.

One of my more recent analogies I use in training (I love analogies as it makes theory more palatable for the students) is that there are yet undiscovered tribes in the Amazonian rain-forest that are using ITIL Incident Management. Not that they would have ever heard of it, or have any procedures, but if something breaks, they’ll fix it!

They’ll notice it (logging), try a quick-fix (initial diagnosis), ask someone else to help (escalation) and end up with a temporary (workaround) or permanent (problem\known error\change) solution.

Writing things down, formalising things into process manuals and procedures (and work instructions and …) is often seen as the key to an ITIL implementation. It is also the ‘downfall’ of many ITIL implementations as it now becomes bureaucracy. I have put my thoughts on this down many times (for instance in http://itilzealot.blogspot.com.au/2012/11/process-for-process-sake.html) so in short: documentation helps to make a process repeatable, manageable and guaranteed (including the activities within). Whether and how much documentation you need depends on your current situation (are your actions already repeatable, manageable and guaranteed?), and the size\risk\complexity of your organisation.

DOING an ITIL process is not determined by whether or not you have formally implemented process manuals, staff training etc. but whether you are following common sense, preferably aligned with the best practice theory. So indeed, as per Rob’s comment: who DOESN’T do common sense (across all lifecycles, processes, …)?

the ITIL Zealot
January 2013