Is ITIL dead?

Why ITIL must adapt if it is to remain relevant in the Digital era

ITIL is dead! A contentious view? Almost certainly, and I don’t think I’d need to throw a stone too far in any direction before I hit somebody that fervently disagrees with me.  So why do I say this?  One word – Digital.

Don’t get me wrong, ITIL still has its place, and many, many organisations are still using it just fine, thank you very much. But the writing is on the wall.  Digital is here to stay, and slowly but surely (and in some cases very quickly!) we are beginning to witness a wholesale shift in enterprise technology strategy from traditional, legacy IT service delivery to a model that is embracing the Cloud (in all its guises), platform and device mobility, automation (everywhere!), and focus that places customer experience front and foremost on the list of priorities.

Whilst ITIL can and does still enable the delivery and support of these technology objectives, it is rapidly being considered ‘clunky’, and organisations are increasingly seeking to adopt more flexible operational governance that aligns more sensitively with the change cadence required, nay dictated, by such advances.

Digital technologies, by their very nature, tend to be fast moving and highly volatile. Development of these technologies predicates an equally fast moving service lifecycle to ensure that customer expectations are both met and maintained in a customer environment that now demands swift and constant improvement and innovation.

Agile is one part of the industry’s response to this challenge.

The recent proliferation of tools and techniques to support Agile delivery frameworks is an indicator of the steady rise in adoption of iterative work cadences, and the reality is that many traditional ITSM framework implementations simply aren’t geared up to support this approach.  In many cases, ITSM actively works to impede the delivery of change in an agile manner, and this creates a very real dilemma for IT service management leaders.

The crux of this dilemma is as follows:

  1. Many of the core ITIL processes have been designed to protect production operations from the impact of change, and manage any impact of that change accordingly
  2. Agile (and supporting frameworks) have, however, been designed to increase the velocity of change, and the flexibility by which it is prioritised

As every Change Manager will no doubt surely confirm, increasing the rate of change (potentially to daily or even hourly increments) can put major stresses on a process not necessarily designed to work at this pace. Equally, the concept of ‘trust’, so fundamental to the Agile methodology, may sound great in theory, but is not so alluring in practice when you’re the Head of IT Operations with SLAs to meet and audit controls to adhere to.

In the Waterfall world change, to a degree, works coherently with ITIL and the phased approach to delivery (design, build, test), gives service management functions the time and space to perform the necessary activity required to protect service.  In an Agile world, however, this paradigm is challenged, and what were very well structured, methodical, and well understood governance controls, suddenly become a blocker to the realisation of business value (at the pace with which the business wants to realise it). In some cases this can happen almost overnight, as businesses take the decision to cut to iterative software development methodologies in a big bang approach, often with scant regard for the impact on service management and operations functions.  Almost instantly we witness the clash of worlds (Old versus New).  And word to the wise my friends, the business is normally championing those in the New camp.

It is at this point that we hit the dilemma.  What takes priority – the rapid realisation of business value through the swift release of change, or the protection of production systems (and thus the customer experience) from potential availability or performance degradation as a result of change?

The answer depends heavily on the type of organisation and system/service being changed, but of course the real answer is that both are equally important.  The issue, however, is that Agile is considered new, revolutionary, and progressive (it isn’t really but that’s beside the point). ITIL, on the other hand, is considered by many to be overly bureaucratic and a constraint to the realisation of business value. And remember, perception is reality, especially when those doing the perceiving also happen to be holding the purse strings.

The result is that IT service leaders, in the face of a business strategy that promotes a fast pace of change that it is perceived to be constrained by service management control, quickly become guilty by association. An inability to respond quickly to this challenge will only compound the issue.  The next logical step from there is the disintermediation of IT altogether, as business change leaders look to more flexible ways to deliver value to their customers, unhindered by legacy constraint.

To avoid this scenario IT service leaders, and the processes that they adopt, must adapt. Long term proponents of existing models must wake up to this notion. This change train is most definitely coming and it’s not showing any signs of slowing down.  We have a lot of baggage to carry, so getting on the train will be hard, but it’s also absolutely necessary (I think I may have stretched that analogy a little thin).

Thus ITIL, whilst perhaps not dead per se, is certainly badly wounded and in desperate need of triage.

As Ralph Waldo Emerson is famously quoted as saying, nothing great was ever achieved without enthusiasm. Well now is the time to get enthusiastic, because if enough of the community are, perhaps ITIL might just survive after all.

What do you think? Leave a reply below or contact me by email.

What IT service management can learn from CrossFit

Six months ago, when my children told me I was “great to bounce on”, I decided to sign up at the local CrossFit gym. I’d heard from friends that it was a good way to get in shape fast. CrossFit has a reputation for being somewhat tribal, with participants enthusiastically cheering, back-slapping and wearing garishly coloured clothes, so it was with some trepidation that I signed up for the induction to my local ‘box’ and set myself on a course to…

Forge. Elite. Fitness.

Two days later, it hit me hard. I couldn’t bend down far enough to put my socks on. Even brushing my teeth hurt! My head was full of acronyms such as WOD, AMRAP and EMOM and strange expressions such as “I totally RX’d Linda today, but I know I can lift more on the clean.” In short, I was a confused and broken mess. But something inside me clicked. I liked it and strangely, I embraced the pain. I was hooked.

I gave myself a week to recover and then bit the bullet and stepped back into the fray, partly because of what it could help me achieve over the longer term. I knew results wouldn’t come quickly, but with perseverance I was sure I could reach my objectives.

As weeks have turned to months, I’m still going, getting fitter, faster and starting to become a little less bouncy around the midriff. It still hurts, but I push past this and keep going because the will to succeed outweighs my desire to be a children’s trampoline.

For me, IT Service Management sometimes feels the same.

Bonding through adversity

It can get pretty intense in the box. Everybody is competing against themselves and the pain is very real even though the barriers to success are often more psychological than physical. A strong spirit of gym camaraderie is essential in getting the best out of everyone. Encouragement and praise is plentiful and audible; this helps maintain commitment and energy levels even when the going gets really tough.

It’s the same in an operations team that works in a fast paced, high pressure environment; a strong team spirit is essential in maintaining throughput of work and ensuring the team does not burn out. Give support to your colleagues, whether it’s a pat on the back, a well-timed joke or a few beers, it can make the difference between a team coping and falling apart. Get to know one another, trust each other, and enjoy working together.

Speaking a foreign language

“What on earth is an AMRAP?! You jerked what?! Your favourite Girl is Nicole?!” Such are the musings of a CrossFit newbie, as the acronyms and bizarre phraseology make CrossFit initially impenetrable.

IT Service Management (ITSM) can be just as bad. To the non-initiated, the fact that an issue is not the same as an incident which is not the same as a problem can be something of a conundrum. ITSM has an abundance of acronyms, abbreviations, and terminology that means nothing to your average developer, let alone the Chief Finance Officer (when you are trying to explain why you need £10K for that critical but under-performing SAN array).

I don’t think that’s a bad thing. Sometimes it helps to feel you belong to a private club that shares the same goal and interest. Having a common language helps us talk in a consistent and professional manner.

Scaling enables continuous output

At its most basic, scaling is the use of tools or alternative techniques to make CrossFit exercises easier and is particularly useful when you are starting out. Many routines (such as pull-ups) are beyond the reach of most mortals, so anything that makes the job a little bit easier is a godsend. It’s not cheating; it simply allows you to progress at your own pace and, most importantly, maintain it.

Going lighter isn’t the enemy to CrossFit. Stopping mid-workout is.

This is equally true of ITSM, where the ability to consistently deliver and maintain throughput is key to successful operations. Overburden a vital function and you might as well rip up that forward schedule of change.

We need to scale our operations. The use of tools to automate processes can pay massive dividends through the release of resource. If a process is slowing you down, make it more efficient. This doesn’t have to involve full blown Lean-ITSM. The removal of just one redundant step could mean the difference between getting that change deployed on time and missing the deadline. Consistent throughput of work though the removal of constraints is the key here.

Again, but faster

CrossFit is about getting stronger, faster, leaner and tougher. Athletes achieve this by performing an activity, analysing their performance, and then seeking to improve on this the next time round. CrossFit continuously encourages you to try to go that little bit harder, push that little bit more and find that last little pocket of energy you didn’t even realise you had.

ITSM should be like this. We face criticism for being overly bureaucratic, cumbersome, expensive or ineffective. These criticisms are not without merit and, like my ever-expanding waistline before CrossFit, are often the result of apathy and a reluctance to look introspectively for the source of the problem.

Continuous improvement processes should strive to first understand the baseline. Once this has been established, they must analyse the system to find out what can be added, removed, refined or improved to accelerate the flow of work. Then rinse and repeat. The team should always be challenging itself to go faster and improve performance but not at the expense of the overall machine. The value chain is only as efficient as its weakest link, so focus on the least efficient components first and make sure that when you cut out the fat, you are not losing some of the muscle with it.

“Having arms like Arnie won’t help you run any faster!”

Shout it out

“There’s only one rule of CrossFit and that’s that you never, ever, stop talking about CrossFit!”

CrossFit people can get a little obsessed and it does have a tendency to border on the intolerable for non-CrossFitters.

In my career I’ve come across a lot of ITIL* evangelists; hardcore supporters of the cause, unwilling to accept that there may be other ways of working or that, just perhaps, full blown change control isn’t required to reboot that printer in the lobby. But ITIL and ITSM is something to get passionate about. When I first found ITIL it was nothing short of a revelation. Here was an approach that allowed IT organisations to shine, add value and actively demonstrate, with meaningful metrics, how and why they were doing a good job and making a difference.

ITIL has come a long way since then, and now has global support in industry, but we shouldn’t be devout followers, deaf to all criticism. ITSM practices need to adapt if they are to keep pace with cloud, digital, and similar emerging technologies.

We have built ITIL and helped to promote the ITSM movement that has radically transformed the way that businesses have operated IT and it’s just as relevant now as it ever was, if we keep it fresh.

That is some achievement and, just like CrossFit, I think that is worth shouting about.

What do you think? Leave a reply below, or contact me by email.

(* ITIL – formerly known as the Information Technology Infrastructure Library)

Continual service improvement – the clue’s in the name

Many organisations struggle to implement effective continual service improvement (CSI). Many purport to deliver CSI but are paying lip-service to the principle and missing the point. The clue is in the name.

Continual

CSI is not a once a year workshop that creates an actions list that sits in a dark recess on a shared drive for the next eleven months. It’s a consideration for every day. What isn’t working? What causes your team pain? You can even think of it from a selfish perspective – what bits of my job do I hate and why do I hate them? How can I improve them so I don’t hate them anymore?

Service

What you are providing is a service. It’s not a contract (though it is likely to be contractually bound). We hear more and more about customer experience yet we forget that we, as service professionals, are providing a service to our clients, not a list of activities or outputs. When considering CSI, ask yourself how your service feels to a customer and think about what you can do to make that experience better.

Improvement

Too often, people confuse change with improvement. Just changing something doesn’t make it better. When you are looking at ideas for CSI activity, make sure it is a measurable improvement. Can you articulate how it will make something better and measure the before and after so you’ll know if it had the desired effect?

It doesn’t have to be a tangible improvement like cost, speed or quality; intangible improvements that make a service feel better can be just as valuable, though you still need to measure the improvement (e.g. improved customer satisfaction scores). Either way, you must be able to define the improvement. If you can’t, then it probably isn’t an improvement. It’s just a change.

So, keeping the name in mind, why not dust down that CSI process and tear up that year-old CSI log?

Start afresh and enjoy the opportunity to be truly creative.

Don’t let ITIL get in your eyes

Driving to work today, the sun was low in the sky and it made it hard to see clearly.  Pulling down the sun visor helped but if you’re like me – vertically challenged – it can have a limited effect.  So it was a difficult journey because the sunshine, though welcome, obscured the view.

I think ITIL can be like that sometimes.

Some people worship at the altar of ITIL as though it is there to be obeyed at all costs. You must do it like this; you must have this process in place; you must implement this tool.

In our desire to adopt ITIL, we forget that ITIL was never set up to be a religion. ITIL is guidance, not God.

As a consultant, it can be easier to step back and see the bigger picture, because we are not caught up in the weeds of day-to-day service operations. The flipside is that we can be a bit evangelical and over-zealous.  And that’s where the balance needs to be struck.

In reality, a full-blown incident management solution is great, but if a spreadsheet and a one-page procedure will do, then we need to suggest that. Not deliver two-hundred pages of shelf-ware and a sexy top of the range piece of kit that takes months to implement.

A good consultant will know the Albert Einstein quote and suggest a solution that “should be as simple as possible, but not simpler”; one that will get you started on the right path and will lead you to the promised land of an ITIL-aligned solution that best serves your business’s needs.

Rather than being blinded by the ITIL sunshine, if your sun visor does not provide adequate shade, a cushion on your seat can be a better solution than hiring a chauffeur or buying a new car.