This revelation is not surprising, given that most everything in IT is complex. More to the point is that ITIL doesn't attempt to hide its complexity under a simplistic facade (a phenomenon I call the iceberg factor).
In fact, the goal of ITIL is to expose the complexity of IT service management. In doing so, this best practices framework tends to raise more questions than answers. And there's the rub (as the Immortal Bard would say).
So, is ITIL best practices too complex for all but the largest enterprises?
Building a House
In a recent article by well-known commentator and ITIL skeptic Rob England, the author lambasted ITIL for not answering four big questions. The article started out on the right foot by stating that ITIL is not prescriptive and does not provide a plan for implementing IT service management. This insightful utterance should be emblazoned across all ITIL books just to ensure it's clear to everyone.The article then deteriorates into the author's usual rant on the deficiencies of ITIL, decrying its inability to effectively guide you on the implementation journey (you can read it here). And, the four big questions ITIL doesn't answer? Well, they are:
- Should you do ITIL?
- To what level should you do it?
- How do you do it?
- How do you show you did it?
1. Should you do ITIL? The answer depends on your specific situation. A house blueprint won't tell you if you should build a house. You'll have to decide that based on your specific needs, hopefully before you draw up the blueprint. It's the same with ITIL. You should decide if you need to improve your IT service management processes before considering ITIL as the solution.
2. To what level should you do it? Again, it depends on your needs. Which processes are suffering the most? What resources and budget are available for this effort? Your final house blueprint could differ based on how much you can afford to spend and how many rooms you need.
3. How do you do it? I can't believe the author asked this question after pointing out that ITIL is not prescriptive. ITIL describes in detail what you should do, but not so much how to do it. However, ITIL does suggest using the PDCA (plan-do-check-act) methodology. Exactly how you apply ITIL depends, again, on your specific situation. If you don't know how to design and build a house, hire an architect and contractor to do it for you based on your input.
4. How do you show you did it? Once again, unbelievable. A basic principle of ITIL is to demonstrate improvements with metrics. Showing that you built a house is easier because you can see it and touch it. IT processes are more abstract and require specific measurements to show their effectiveness. Starting with baseline metrics for your current processes, it is fairly easy to show how (or if) changes to your processes are more efficient and effective.
Keep It Simple, Shakespeare
Mr. England also dismissed the notion that you can focus on just one or two ITIL processes at a time as "patently rubbish." He claims that ITIL processes are too "intertwined and interdependent."First let me say that, having read many of his articles, I have great respect and admiration for Rob England. Although I agree that the ITIL processes have an interdependency, which is a major contributor to ITIL's complexity, I believe you can improve a specific process without addressing a number of processes at once.
ITIL V3 recasts its processes in a life-cycle phase model of strategy, design, transition, operation and continual service improvement. V3 suggests you approach ITIL by cycling through these 5 phases, each of which is described in a separate book.
This would be great if you're just starting your IT organization. But since most IT organizations already exist, it would be impractical to follow this structured phased approach (this is where academia and reality clash).
A more pragmatic approach is to identify the areas that need to be improved the most. Start by asking a few simple questions such as:
- What services does IT provide to the organization?
- How does the business use the IT services?
- Which services does IT do well and which need to improve?
- Which "squeaky wheel" process needs attention now?
Regardless of the methodology used, decomposing complex ITIL objectives into small bite-size tasks along with an iterative PDCA cycle simplifies the work and reduces the risk of failure. Keeping the scope of each change small, and delivering the changes quickly and often will provide the greatest benefit for your users.
Getting Started
When you define process improvement objectives, you also need to know how to determine if you've achieved the objectives. Typically, process improvements are measured in terms of higher quality and efficiency. The key word here is measure.There is an old axiom that states you can't improve what you can't measure. This is especially true with ITIL. Creating a baseline by measuring your current processes is a necessary first step. And before you can create a baseline, you need to decide which metrics you will use.
The metrics you use depend on the particular process you are measuring. Metrics can be based on subjective qualitative user satisfaction surveys, or objective quantitative measurements. Metric types include technology performance and availability, process performance, and service results. However you define them, your metrics can show the success of your improvement efforts.
Improve Quickly and Often
Getting back to the original question of whether ITIL is too complex—perhaps it is. Attempting to address all or even several processes at once is very risky, especially if resources are limited.Attacking your processes little by little, making small improvements over time, is key to successfully adopting ITIL. This is the basic principal and central theme of the fifth phase/book of ITIL V3, Continual Service Improvement or CSI.
Existing IT organizations already have their services and processes in place. CSI is the optimal approach for established organizations, and this phase of ITIL does include guidelines for implementing improvements using vetted methodologies such as PDCA. With CSI, you define your critical success factors (CSFs) followed by key performance indicators (KPIs) and supporting metrics.
In any endeavor, the success of the outcome is directly related to the investment in planning. I cannot emphasize this point enough—proper and adequate planning is the most critical factor for success. Plan, plan, plan!
A Never-Ending Story
ITIL may seem complex and overwhelming. So are many other things in IT. But complexity is not a reason to ignore it. Don't dismiss ITIL as a risky, difficult undertaking. The benefits of this best practices framework are too great to ignore. By breaking down a complex system into simplistic components, you can mitigate the risk.Continually repeating an improvement process will move the quality and value of your IT services higher. Use the CSI 7-step process (see "ITIL V3 Lifecycle And CSI") to improve quality and increase the value of your IT services. ITIL may not answer every question, but it does tell you what to do, and V3 provides guidelines that tell you how to improve your IT processes and services.
References:
Bon, J. van (chief editor) 2007. IT Service Management Based on ITIL V3. Zaltbommel: Van Haren Publishing for itSMF. ISBN 978-90-8753-102-7.
By Harry Hiles, HBH Technology LLC — 3 Feb 2009
An Introductory Overview of ITIL V3
