Just how big an impact has ITIL V3 created?
It is now five years since ITIL Version 3 was launched, trumpeting the new focus on services and service management loudly and pervasively. This new focus was pitched as an innovation, expanding an outlook previously limited to operations as applicable across the entire, cradle-to-grave service lifecycle.
Although ITIL has seen another update since then—the ITIL 2011 release last year—that release is largely about the enhancement of existing ideas rather than making major changes to the scope or scale of those ideas.
So it makes sense to talk about the last five years of the ‘ITIL service lifecycle’ and ask ourselves what its influence has been.
Now, admittedly that’s a big subject to discuss, and discussing it gets more complex when you consider related issues like these:
Many IT organisations had already been focused on services, customers, and the full service life perspective before ITIL Version 3.
It isn’t always totally clear what is, and what is not, part of the service lifecycle—how does it fit with the application lifecycle and project management, for example?
The IT world has experienced many major changes over those five years—for instance, cloud computing, smart mobile devices, and the recession have each influenced the IT world tremendously since 2007.
Even so, it seems reasonable to me to talk about the significance and influence of ITIL V3. So let me pick out my two favourite and, I feel, significant service management concepts in ITIL V3, and then ask if those ideas are more or less prevalent now than they were back in the V2 days.
Service design: How well is IT taken into account from day one?
"It stands to reason that for the best service to be delivered to customers, the application needs to be created, from the start, with that service in mind. The technical elements that comprise the airplane should be selected and integrated without losing sight of the larger goal of service management. And indeed they are."
Firstly, just think about the term ‘Service Design.’ This, to me, is perhaps the most important concept in ITIL V3.
‘Service Design’ is the idea that we should define a service as a way to meet customer needs—and only then ask ourselves how best to pursue that goal via technology in a complex infrastructure (specifically, what kinds of best practices might apply).
Such an approach is certainly not characteristic of the way IT began in most organisations. Historically (in the banking industry for instance), IT focused on writing code to support specific functions. And of course that still needs to happen.
But IT has grown up—a bit at least—since the days when it saw itself as just creating specific technical cogs used in the machine of someone else’s service. Nowadays, it’s understood that the IT application should be designed from the beginning as an integral part of the business service—which is exactly the message ITIL V3 set out to deliver.
To be fair, this wasn’t exactly a from-scratch, innovative message. After all, ITIL isn’t meant to be completely original; instead, it’s meant to collect, organise, explain, codify, and polish the best practices that have already been developed by successful organisations, so that others can benefit as well.
In fact, like many of the ‘maturing’ ideas that are increasingly influencing IT people, service management is a time-honoured engineering concept that has been widely applied in other fields for decades.
Consider how it’s applied in aerospace engineering, for instance. The service there, of course, is transportation. The “application,” in this sense, is the aircraft.
It stands to reason that for the best service to be delivered to customers, the application needs to be created, from the start, with that service in mind. The technical elements that comprise the airplane should be selected and integrated without losing sight of the larger goal of service management. And indeed they are.
How does this manifest? Many ways. Here’s one: airplanes are sold with a choice of engines—but the designers have established those engine options before finalising their airframe designs. Some engine options might support the transportation service better, some worse, and some not at all (such as maintenance being unavailable in some parts of the world).
It is similarly apparent that we should design logical services with IT options in mind from the start too. And I credit ITIL V3 with helping to make that idea much more pervasive than it had been before.
But it’s still not as pervasive as it should be. We’re still not realising all the benefits from ITIL V3 that we could, and should.
In my opinion, that won’t happen until IT sees itself as a platform of business service delivery much more commonly, and comprehensively, than it does today.
And here’s the flip side of that coin: far more business people need to understand that for services to be truly successful, those services will need to incorporate IT knowledge and awareness from the start, and at a deep level.
Service management concepts can create far more value than they typically do today
Maybe a hypothetical example will help illustrate these points.
Imagine that a major retailer partners with a chain of petrol stations to offer classier goods in the filling station’s shops. Sensible move, because there’s clearly an untapped market: commuters going home after a long day at work, who want an easy place to buy tonight’s dinner and perhaps a bottle of good wine too. We can conceive of this as a new service.
Now the question becomes: How best can we implement that service, both in terms of customer satisfaction and in terms of internal goals like performance, cost controls, simplified management, cross-domain integration, etc.?
The temptation is to take IT as it already exists and simply bolt it unchanged onto the new service. But things get trickier at this point.
To wit, the retailer’s entrenched sales and stock system—originally developed by IT for huge supermarkets with dozens of checkout lanes—turns out to be overkill for petrol stations, and it supports only a single price per item. It creates a significant overhead. This means that the profit/loss forecast doesn’t look remotely as good as in initial projections.
Now let’s imagine that instead, the new service was developed with IT service management concepts in mind from the start.
In this scenario, a service management team might ask questions that the store-building team might not. It could establish very quickly that by dialing back the technical implementation—minimal contingency, lower availability requirements, perhaps even less functionality—it would be possible to reduce IT costs without compromising service quality. The key is realising the different service management requirements in the filling station store—where failure has considerably less impact (and publicity) than would come from losing a superstore for a few hours.
Well, that alone could easily mean the difference between success and failure of the entire project. And such an outcome can only be achieved if you interpret service management as an asset that delivers benefits in its own right, and leverage that asset as intelligently as you can.
Service improvement: Don’t lose sight of the forest as you grow the trees
What about the stages after design? In particular, once a service is up and running, how best can you enhance it to be more efficient, cost-effective, and suit changing needs and goals?
This question brings us to the other major ‘service’ focus in ITIL V3 (to me at least), which is about service improvement.
(I’ve deliberately omitted the word ‘continual’, as in ‘continual service improvement,’ because despite ITIL guidelines, I don't mind a bit of intermittency in how improvement happens, just so long as there is enough momentum to deliver benefits.)
The perennial problem with service improvement is one of focus. Many times, it seems organisations only ask “How can we do X better?” when they should first be asking, “Is X the best way to deliver this service?”
The danger is that you—and your people—can end up working long hours, striving really hard to get better and better and better... but only at how you deliver the wrong thing.
Consider the following quote attributed to Henry Ford: “If I had asked people what they wanted, they would have said faster horses.”
You can interpret this quote as being anti-research—i.e., “There’s no point in asking what people want, because they’ll just give you wrong and short-sighted answers.”
But I don’t think that’s really the best interpretation. To me, this quote underscores the problem you’ll often run into by focusing too much on the means and mechanics of improvement, instead of focusing on customer needs and the value customers get.
Imagine you want to move goods from A to B more quickly, and that you currently use lorries.
One solution would be to focus on the mechanics: deploy bigger lorries, which can carry more goods in a single trip. And to deploy bigger lorries, you need to upgrade the roads.
Fair enough, but if there are bridges that won’t support the bigger trucks, you still haven’t improved the service of moving goods. You’ve only wasted lots of time and money on lorries and roads (and this will become apparent the first time a lorry loaded with goods falls through a bridge).
In an IT service management context, the same problem happens all too often.
Suppose you ask your specialist capacity management team for a forecast of the technical resources necessary to support a projected workload. It is quite likely that they will disappear for a few days and come back with a figure, apparently precise to 0.1%.
But in fact your business forecasts are only accurate to ±20%—and even that assumes the recession will go away and it won’t rain too much.
Ergo, if the capacity management team is spending multiple days trying to exceed that level of precision, their assessment process is far too rigorous for the service it’s meant to support. They will have been trying very hard to do the wrong thing—and spending your money to do it.
After 23 years working for the UK government, moving from forestry to IT Service Management via prisons, stores and training, Ivor now works for IBM’s Tivoli organization helping customers understand and improve their Service Management. Ivor was an ITIL author (versions 1, 2 and 3), part of the panel that wrote BS15000 (fast-tracked to ISO/IEC 20000), an ITIL trainer and examiner since 1991 and active in itSMF since 1995, having spoken for them in 34 countries.6
Discover a bright new day for your application infrastructure
Register now for the IBM SmartCloud briefings in Boston, Austin or Washington D.C. and in just one morning you’ll get the most information for improving your infrastructure with techniques and solutions that help you better connect across existing IT and Operations silos.