Quality over Quantity?

I returned from holidays last week and boldly started 2014 with a ‘polarising’ tweet:

OK, I'm back from holidays and have stepped into 2014.What's new? Has @AXELOS_GBP messed up #ITIL yet? #ITSM

Admittedly quite a blunt tweet, but I was hoping for some responses and got exactly what I bargained for with specifically two interesting ‘discussions’ following (using the term lightly as it was all in 140 character twitter statements, thus lacking some ‘finesse’).

One was rather obviously about AXELOS’ performance to date. More on that later, but first the other discussions which diverted into whether (ITIL) training should be of the best quality or the most accessible. John Custy (@ITSMNinja) mentioned that if ITIL exams were more expenses (based on AXELOS’ price increase) ‘maybe fewer, but more right people certified...’

This got me thinking, as I have always been a great advocate of training quality and a skeptic of the current ITIL certification scheme (see my blog from March 2013 on Action Based Learning).

However at the same time I can see the importance of training be accessible to a large audience, particular at the basic/entry/foundation level. Hence the title of this blog: Quality over Quantity/Accessibility.

The current ITIL Foundation course (or rather ‘Foundation Certificate in IT Service Management’) has become a volume-seller with around 20,000 exam each month. Plenty of organisation are sending all their IT staff to this course and the prevalence of the ITIL Foundation certificate has certainly helped to make ITIL the ‘de facto’ standard in IT Service Management.

Compare this for instance with COBIT. COBIT is seen as an equivalent if not better alternative to ITIL (with more prescriptive guidance, standard RACIs, a direct link to governance, risk, project management …). However, whilst there are COBIT qualifications available, it comprises mainly of Foundation, with then ‘specialised’ implementation or assessor courses which are not focused on general staff. And it is much harder to obtain with fewer organisation (in fewer locations) offering this course less frequently (although there is always the on-line option).

And it is a similar story with MOF (Foundation only), TOGAF (Foundation or Certified qualifications), LEAN or AGILE. Whilst there certainly is certification in those methodologies, it is far less known, far harder to obtain (not because of difficulty but because of availability) and far less recognised.

As mentioned, I believe this is part of the success of ITIL and in order to maintain this it is important that AXELOS not only maintains the quality of the ITIL certifications, but maintains or even improves the availability/accessibility/quantity. Most certainly at entry/Foundation level but also for Intermediates, which have a far smaller uptake. The more people are trained and certified in ITIL, the more people will want to use it (and the more people use it, the more we can work towards quality improvement of the theory).

That doesn’t mean that quality is not important. And whilst I hope that future updates to ITIL will improve the quality of the theory, and with it the quality of the certification (for instance a lower, operation-only Foundation, more practical and less factoid based, periodic exam refreshers to maintain higher levels, …). We need to look at the situation at hand: The Foundation is course is so prevalent that a lucrative and significant grey circuit has developed offering courses that do not (always) meet the existing quality standards. This (in my opinion) is a real threat to both AXELOS, the ATOs and the market.

For instance I believe we can all agree that the existing ITIL Foundation syllabus only just fits in a three day format. There is a lot (too much!) theory to explain and the danger is of the course becoming death-by-powerpoint, theory-overload with not enough time to discuss practical application of the principles. So, I was not overly impressed when I was approached by a (non-accredited) training organisation with the question whether I could deliver the Foundations in two (albeit extended) days … over a weekend … including the exam. I declined and sincerely question the quality and outcomes of a course like that.

Because as important as certification is, there is more to training than that. However we need to look beyond the IP-owner and training organisations and realise that it is the responsibility of the organisation/manager who sends staff to training to obtain ‘value’ from it (as well as the staff attending training). I advocate an immediate follow-up on training: at Foundation level an attendee could do a review of existing procedures, tools and documentation (and discuss any questions or suggestions with the process manager/owner). At Intermediate level this can become a more formal assessment and CSI/SIP and at Expert level the scope increases (all lifecycles) and would include tactical or even strategic customer relationships.

Anyway, bringing this rant to a close: the quality of training is paramount and any customer/participant of training is responsible for choosing the best training and getting the most out of it. The better training organisations (and fortunately there are plenty of them) will maintain quality and inject this into their offering.

The role of the ‘examiner’, in our case AXELOS, is to design a qualification scheme that is acceptable by the market, but also to maintain a delivery model that will make it available to that market.

Whilst this includes maintaining quality (EIs, ATOs, …) there is more to it. And a first action of increases the price of exams (and thus their revenue) does not necessarily give out the right signal. But that is a different discussion (on AXELOS’ performance, which I promised Andrea Kis (@AndieKis) to have in 170 days).

Best wishes for 2014!

the ITIL Zealot

January 2014

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

Service Management basics

Happy New Year

Somehow I thought I would be able to write my blogs ahead, and then release them fortnightly (or at least two-a-month). Reality has taken over and I now find myself in January without any pre-prepared blogs. So, with this in mind and as we’re starting a new year, I thought perhaps I should go back to the basics.

As an ITIL zealot, I of course am strongly inclined to see ITIL as the one true way of ‘implementing’ service management. But I am certainly not that myopic not to recognise that there are some excellent ‘other’ frameworks around which offer complimentary and sometimes even superior advice (I am particular enarmoured with COBIT5 and may devote a future blog to that).

But more than any specific methodology I find that recently I am spending more time (in ITIL training etc.) explaining to people the basic concept of Service Management (and then how ITIL fits in). So, the basic concept of service management is the management of services (yes, sometimes things are THAT simple). A service, in turn, is the value we deliver to the business, which is not related to any specific technology used (but rather the utility and warranty, which are a great set of concepts, although ITIL could have used them better and more consistent).

So, my first and possibly most basic teaching is that we (i.e. all ‘IT-people’) need to focus on our deliverable\value rather than our delivery\technology. This is most evident in a process like Incident Management that deals with break-fix. ITIL provides a great objective-statement for this process which is ‘to restore normal service as quickly as possible, and minimise impact on the business’.

I always highlight three key parts in this statement, the first being ‘restore’. Incident Management is not about fixing, improving or anything permanent\long-term, but merely about restoring the normal\working situation, sometimes using workarounds (the equivalent of taking an aspirin …). The second highlighted part is ‘as quickly as possible’, which then leads to the priority-setting (impact and urgency), which is driven by the customer, business or at least the service targets of the SLA.

The last part of the Incident Management objective that is of importance is ‘minimising impact to the business’, which brings us back to the core of service management: delivering value. If a user can’t email, then it is important of us to restore this service (and for future purpose perhaps do a root cause analysis). But of immediate importance is the business process which was trying to communicate (the value), something that perhaps can be achieved otherwise (print & fax, phone, …). A good service desk agent will think with the user, about the business and not restrict themselves to the service levels in place and/or the technology used.

Once you grasp that the basic meaning of a service is the value delivered, then the next\second basic concept is that of the ‘management’ part: the value has to be delivered repeatable & guaranteed. This is where ITIL (or your favourite methodology) plays its part as it provides the structure that allows providers to deliver services repeatable, manageable & guaranteed. 

In ITIL this is done through the processes which provide ‘structured activities’. This is why a good methodology is also known as ‘commons sense, written down’ as those activities are common sense and most people would do them anyway, most of the time (I sometimes joke that there are yet undiscovered tribes in the amazon who are using Incident Management). The structure of a process makes sure that everyone does the activities, all of the time and thus establishes repeatability. By documenting a process (procedure manuals, work instructions etc.) and measuring activities (and outcomes) we make the delivery manageable, repeatable & guaranteed.

But … remember that it was not about the delivery, and thus not about the process, but rather the outcome\value\service that is being delivered. Processes\ITIL are merely a means to an end (even though sometimes zealots like myself get lost in the intricacies of the means, thus forgetting the end)!

Focusing too much on process is the equivalent of declaring the operation a success, even though the patient has died! (but look at the stitching ... textbook).

So, these are the basics of Service Management: it is about delivering value in a repeatable & guaranteed way. Ultimately (or ideally) a service is a fixed-price, blackbox ‘thing’: as a user\customer I don’t care how it happens, as long as I get the value, every time I need it!

Best wishes for 2013.

the ITIL Zealot
January 2013

What is wrong with ITIL training?

ANSWER 1: EVERYTHING

• ITIL Training is just another way for consulting and education firms to get your money
• ITIL Training just focussed on the process theory and facts
• Multiple choice is an inadequate way of testing someone’s capability

I guess from a negative perspective the above statements are true (to a degree). ITIL V3/2011 has made the training path more complex: whereas before it was Foundations and then either Managers or Practitioners, now it is Foundations, either Lifecycle or Capability, or some kind of combination of those and then Expert ... In particular the distinction between Lifecycle and Capability is very unclear with large areas of overlap (for instance Service Operations vs. Operational Support and Analysis) and even more puzzling gaps (little or no CSI in the Capability Courses, limited Strategy, no Design Coordination ...). APMG could have done a better job with positioning the courses, and limiting the options.

The second (negative) argument is that ITIL training is (just) focused on theory. Again there is some truth in this, mainly as most courses will be followed by an exam, which focuses on the theory (see next point). But from Intermediate up, each course is supposed to provide more than 50% practical, interactive exercises. The exception is the Foundations which does require a lot of theory to be explained, and unfortunately due to market pressure, predominantly in a 3 day / 20 hour time span.

I think the 3 days are about the maximum what a ‘novice’ (or manager) can bear, so if we don’t want to tinker with the time-element of the Foundation course, then perhaps we should look at the content. Years ago a rumour surfaced that the Foundation course might be split in two: one basic with Operations & Transition; and one more ‘advanced’ with Strategy, Design and CSI. I thought this was a great idea, but unfortunately it never materialised. 

Most consulting\training firms, or in-house training organisations will have developed an ITIL Overview or Introduction which provides the basics in one or even half-a-day. And because there is no exam-pressure you can focus on the key-concepts.

And therewith we come to the biggest argument, which is that the exam ruins a good course. I think no-one will deny that multiple choice exams are an awfully inadequate way of testing someone’s capability (no matter how much 'Bloom's taxonomy you throw in). And unfortunately the ITIL multiple choice exams are no exception. At Foundation level the question often require knowledge of specific, theoretic factoids. Something that could be easily found in the ITIL documentation (, pocket guide or glossary-of-terms) and therefore hardly a necessary skill or capability. It should focus on the larger concepts of Service Management, the lifecycle and the key processes, perhaps with small (one or two paragraph) scenarios.

The Intermediate exams are slightly better with ‘scenario-based, gradient-scored’ questions. These questions at least relay the message that not all answers are wrong or right, but that some are ‘more right’ given the circumstances. But unfortunately then a significant number of questions still rely on knowing the exact, ITIL way or in other words more factoid book remembering, rather than true understanding.

Taming the Beast of Information Overload
http://www.foundationnews.org/CME/article.cfm?ID=1003:

And at Expert level this becomes an even bigger issue as the difference between the answers becomes smaller and the correct answer (at least in my opinion) almost always is ‘it depends’. With an essay-style question you can get points even if you made the wrong choice, depending on your ‘defence’ of that choice. With multiple choice it is an all-or-nothing. And sorry, I may be overestimating my own ITIL power, but if after 20 years of almost daily working with the material I still score a 0-point answer (on the MALC), I actually believe there is something wrong with the question, rather than with me or the theory.

ANSWER 2: NOTHING

I admit that all of the above arguments hold an element of truth. However, I think that in the end it is up to both the course candidate and provider to achieve a satisfactory outcome.

The provider of the courses needs to work within the syllabus (and exam requirements) but most courses give ample opportunity to add examples, exercises, discussions and other elements to ensure understanding and provide practical guidance.

The candidate also has a responsibility. If they just come to the course to be a few days away from work, or expect to find a silver service management bullet that will be spoon-fed to them (oops, mixing some metaphors), it will be a disappointing experience. The candidate needs to be open to learning, participate in the course, question everything (most trainers will welcome the challenge of questions as this will allow them to expand on the theory and provide insight for not only the questioner but the other participants too) and ensure the course enhances their understanding. I think it should be mandatory for candidates to create a next-steps plan after each course (and for their managers to demand, verify and control these).

The exam is just a bump in the road, and fortunately with thorough understanding of ITIL and a modicum of learning the exam can be easily passed (perhaps not with a 100%, but passed nonetheless).

In a future blog I might address the various type of training (on-line, classroom, blended) and well as the customisation or training and creation of a training path (with overviews, simulations, accreditation etc.). But I’ll leave you with a musing on the difference between education and training: education is more theoretic\school-based whereas training has a practical connotation. After all you wouldn't want your teenage-daughter to come home from school raving about the sex-training she had that day!

the ITIL Zealot
May 2012