Some organizations have spent considerable time and money trying to improve delivery of IT services to their customers using ITIL, some are just getting started. The buzz around v3 probably has everyone scratching his or her head – go with v3 or stick with v2?
ITIL v2 contains virtually every in ITIL v3 and ITIL v3 contains virtually everything in ITIL v2. The difference? ITIL v2 is all about process and the goal is improving IT efficiency and effectiveness. ITIL v3 is “more mature” and assumes the (ITIL v2) processes are all in place and the goal is economic optimization of IT.
While ITIL v3 does make some things more explicit and less prone to interpretation, in reality, the v2 vs. v3 question is a non-issue for both those “well down the ITIL path” and those that are just thinking about starting their journey.
Based on my experience, there are three things IT organizations have to master to succeed delivering IT services to their business customers. These three fundamental requirements are met equally by ITIL v2 or v3.
Stabilized Infrastructure – One of the first milestones any IT shop has to achieve is the stabilization of their infrastructure. In simple terms, it means learning how to fight fires, but it also means learning how to prevent fires.
In ITIL terms it’s all about fielding a working Service Desk that provides the point-of-contact the business users can call when there is trouble, or when they need something done. It helps stabilize the infrastructure by providing a stable “touch point” for users; it means no more guessing who to call.
Incident Management is fundamental to stabilizing the infrastructure and establishing the creditability of IT. While many in IT refer to this as firefighting, it’s much more. Good Incident Management contributes to the improvement of availability and the overall reduction of the impact of incidents on the business.
When done properly it is also the definitive source of quality failure data used by other processes; such as Problem and Availability Management. Organization know they’ve achieved their first milestone (stabilization of the infrastructure) when they successfully implement Problem Management. This is significant for two reasons; first is the systematic removal of errors from the infrastructure will dramatically improve service quality. Second, is that Problem Management will free up significant IT resources that can be redirected to other, more productive efforts for the benefit of the business.
Controlled Infrastructure – As IT organizations achieve infrastructure stability the next milestone is establishing control over the physical infrastructure. While this may sound a bit silly, its intended to covey the concept of the IT organization’s need to fully understand the content and context of all of the IT components that make up its infrastructure, and be able to control the content and quality of the changes that are made to it. Organizations that successfully implement Configuration, Change and Release Management can be said to be “in control” of their physical IT infrastructure; they know what they have and can accurately design changes that achieve the desired outcome for the business with minimum risk and disruption to the business.
There is an interesting byproduct of an organization achieving this milestone; the “reactive processes” of Incident and Problem Management are further enabled, primarily through the availability of configuration information. Therefore they can achieve a higher level of process capability and higher levels of service quality. Thus, we see the cumulative effect of these processes, their dependencies and relationships.
Improved Infrastructure – The third milestone is when an IT organization can establish the capability of managing its IT service levels. This is different than just having a bunch of Service Level Agreements, since having a document doesn’t ensure the capability to “deliver on the promise.”
This is a significant achievement since it represents the culmination of the deployment and refinement of the reactive and control processes, as well as the ability to build the necessary warranty (availability, capacity, continuity & security) into the service delivered. It also signals a maturation of both the IT and business organizations whose dialog will have morphed over time from “cost and technology” to “value and service.”
Okay, So What? – Back to my original point; should IT organizations adopt v2 or v3? While the question doesn’t challenge the medieval theological debate of how many angels can dance on the head of a pin, it comes close. Fundamentally v3 adds some additional processes and provides a larger “frame” in the IT lifecycle. All of the processes discussed above are part of it.
There appears to be a lack of perspective in this debate; and that perspective focuses on where an IT organization is; that is, their current capabilities, and the maturity of their organization and its leadership.
My experience has lead me to believe that an IT organization that can’t reliably restore a service or find the underlying cause of an error to the infrastructure probably doesn’t have a handle on the physical components of their infrastructure and can’t demonstrate the ability to make quick and accurate changes to that infrastructure.
Therefore, while the desire to provide Service Level Agreements to their business customers may be great the capability and maturity just don’t exist.
So the question of v2 vs. v3 to an organization just starting out on their journey to operational excellence … well, it just doesn’t matter. They have to get a handle on the fundamentals – and the fundamentals are just as well documented in v2 and in v3.
By doing so, they start to remove all of distractions that keep them from achieving operational excellence, as well as a resource sink (resources go in and nothing comes out). Each step along the path, the achievement of these three milestones improves their previously developed capabilities as well as paves the way for further improvements.
The reality is that until an organization can deal with the basics, the refinements of v3 are over the horizon. Its time to stop confusing the issue with endless debates and articles about the good, bad and ugly of v2 vs. v3 and get on with actually getting something done.