The ITIL glossary needs a defibrillator

In an earlier post I highlighted the fact that ITIL-speak is not aligned with customer terminology.  Now I want to take this a bit further and say that ITIL-speak isn’t even aligned with common IT speak.

IT has a natural language of its own that varies slightly from organization to organization.  To a certain extent, ITIL has tried to go against this in the name of standardization.  Adoption of a global terminology standard benefits the industry as a whole, but does it benefit an individual organization which has already settled on terminology that is understood clearly within the organization?  Naturally, it is very difficult to get people to adopt new terminology in place of a lexicon that has become established over many years, so there are major cultural change issues involved in throwing out something that works for the sake of standardizing with the outside world.  People will not get behind such an initiative because they will not see any value in it – only disruption – which is a fair point.  Standards that don’t bring real benefits to the individual organization fail to take hold.

• IT Manager: "We're calling it X instead of Y now"
• Techie: “Why is that word better than this one?”
• IT Manager: “Because it’s the standard”
• Techie: “Not in this organization it isn’t!”

Indeed, the ITIL glossary is far too cumbersome, with the ITIL V3 Glossary running up a total of 58 pages, there will be few people on the planet who have digested and assumed the entire ITIL dictionary.  Thus, we can never expect mainstream adoption whilst the effort required is so great.  Perhaps terminology should be chopped up into chunks and associated with different processes or maturity levels so that it can be adopted in a focused manner.  After all, there would be little benefit in force-feeding your IT department terminology that applies to processes which are outside the ITSM roadmap.  Once again we find ourselves back in the position of looking things in terms of what is of practical value to us, right now.

 "Mr ITIL, tear down this wall."

To simplify ITIL terminology, each process should have a surrounding cluster of terminology, indicating the standard terminology that is commonly used in the strategic and day-to-day management of that process, including the ITIL, IT and business/customer terminology – and how one maps to another so that it actually helps develop understanding and communication in real life.  This would allow organizations to select a standard set of terminology, but one that fits the context of their own business.

• Customer: “I’ve got a problem with my printer”
• Service Desk Analyst: “Actually, Sir - I think you mean you’re having an Incident.  It will be a Problem when we create a Problem record in our ITSM tool.”
• Customer: “@&#? #$*!”

Organizations that think a change in dialect is going to fix IT won’t make much progress.  It’s about adopting the ideas behind the words, not just the words themselves.

Availability Management: Get rid of the 'nines' and bring in the $$$s.

Availability management is at the core of customer satisfaction.  Without availability, no service is delivered and there is no service revenue.  However, due to the continuous changes in patterns of service consumption, the bottom-line business impact of service downtime ('unavailability' is not a word) will vary from one instance to the next, according to the volume of demand that has not been met, and the value of that demand - after all, not all customers are equal.

IT organizations need to define how service availability translates into revenue.  Availability has become a critical business metric that IT can use to improve service provision and drive increased revenue, particularly for ‘clicks-and-mortar’ e-commerce organizations where downtime equals lots of lost revenue.  Although availability management isn’t the most glamorous corner of IT, from the user perspective it is a key influence on customer satisfaction and thus business success.  If a service is not available, revenue will be lost, the brand will sustain damage and customers will look for other service providers.  Your competitors are only a mouse-click away, so customer loyalty is lost far more easily than ever before.

Why availability is a problem
Many IT organizations are still device-oriented departments, fixated with system uptime as the key availability metric.  These have a grand total of zero relevance to the business. For IT, a ‘five nines’ availability metric (99.999% uptime) may be seen as quite an achievement (about 5 minutes downtime a year), but if that 5 minutes of downtime falls right in the middle of the busiest business period of the year, the direct impact (lost revenue) and indirect impact (brand damage and customer attrition) is likely to be job-threatening.  IT managers who let this happen will have to answer tough questions on why IT wasn’t ready.  IT managers need to understand that downtime is not random, nor does it have a uniform cost every time it strikes.

The Nines - Crap film, crap IT metric

Work from the top down
In the ITIL 3 process map, Availability Management quite rightly sits in the Service Design Processes group, indicating that it is a critical part of the process of designing a service.  Designing high availability into a service is a good start, but there is always a threat of downtime during the operation of the service coming from external factors.  Downtime is always caused by a change of some sort - either a haphazard change applied by the service provider which has impacted the service in an unforeseen manner, or a change in the pattern of service consumption that has resulted in an overload.  Thus, the business needs to be aware of IT changes so they can veto badly timed changes, and IT needs to be made aware of marketing activity that will drive spikes in demand so that they can plan for capacity to meet demand.

ITIL is dead. Long live ITIL.

Isn’t it about time the idea of publishing best practice books was killed off.  It’s an inherently flawed idea.  Yes, the books have served a lot of organizations well - but like any book it’s out of date as soon as it’s printed.  Yes, it gets updated, but not often enough.

ITIL V3

People seem to be drifting away from ITIL and I think this is because it’s presented in the wrong format for the dynamic world we live in.  When will we see a collaborative, expert-moderated ITIL Wiki representing up-to date best practices?

Where a book suffers from a page limit and thus a scope limit, wikis are free to grow and branch out to solve some of the limitations of the ITIL books - like covering more prescriptive best practices for each of the industry verticals.  If ITIL is to survive, it needs to be made more valuable, accessible and pragmatic.

"Hang on, I'll check what ITIL has to say about it"