With the updated version of ITIL imminent (the 29 July 2011), I participated in a BrightTalk webinar on “what next for ITIL.”
My views on this are very clear, that we need to “look back before we look forward.” I touched on some of this in a previous blog, 2011: An ITIL Versioning Odyssey, but think it worthwhile to continue to articulate my views in this area.
Let's start with what I consider to be the biggest issue: the gulf between theory and practice with ITIL.
There is no doubt that ITIL can benefit I&O organizations. There are certainly many I&O organizations encouraging, or even forcing, their people to take ITIL training and qualifications: There are at least 1.5 million people with the certification and there is no sign of this slowing down. Not only are trainers busy, so are ITSM consultants and, of course, industry analysts. But, from an industry analyst perspective, there is a lot wrong with ITIL. This is not just how it ballooned in size from ITIL v2 to ITIL v3, but also how it is adopted in the real world.
So what's going wrong?
If you look at existing ITIL v2 adoption, there is a focus on the reactive elements such as incident management, problem management, change management, and maybe even configuration management and service-level management. How many organizations have moved on to the more proactive elements such as availability management, capacity management, IT financial management, and continual service improvement?
My colleague, Glenn O’Donnell, and I (do I sound like the Queen?) have delivered a Forrester report called “Improving The Ops In DevOps” inspired by the long-bemoaned tension between “change-the-business” (dev) and “run-the-business” (ops) IT teams and their activities, and the need for change.
This tension inflicts a detrimental impact on the business. In fact, most organizations suffer this curse, and stereotypes that reflect this animosity abound. Does this sound familiar? Ops people see dev people as sitting in their ivory towers cranking out code all day and wanting to release applications oblivious to real-world constraints; dev sees ops as cog-turners ensuring that the IT infrastructure doesn’t break under the strain of poorly written code. Chances are that your organization is not this bad. But this exaggeration is indicative of the tension between these two IT “tribes” and their opinions of each other. These stereotypes exist because organizational behaviors do exaggerate genuine conflicts, and both parties must act quickly to change.
Getting DevOps right will address many of the issues enterprises consistently have with IT, such as applications failing to meet both functional and nonfunctional requirements, delivery delays, increased costs, and an inflexibility to change. But is DevOps enough to save I&O from extinction?
I recently spoke with a Forrester I&O client looking for “incident classification best practice.” I knew that I should have had knowledge of this, or at least access to it, but all I had was a loose set of guiding principles that are probably more “common sense” rather than “best practice.” I was happy to talk with the client but wanted to know what I had missed.
Google seemed a great place to start. After all, Googling “ITIL” results in 21 million hits (I do appreciate that not all of these will relate to the IT service management best practice framework though). So I Googled “incident classification best practice” (plus “incident categorization best practice”) and was surprised at the results. Well, the LACK of results. There was no freely available advice or guidance on this subject.
The main reason for my surprise is that, with the wealth of IT service management best (or good) practice out there (especially with ITIL espoused as THE framework of IT service management best practice), this is one area where I definitely think that value could be derived by documenting successes and the pitfalls to avoid.
Given that many organizations adopting ITSM best practice, or ITIL, will start with the service desk and incident management, the creation of a robust incident classification hierarchy is something they will need to do. A similar opportunity also arises when organizations switch between competing ITSM products as part of the well-documented ITSM tool churn. For others it is relevant when the realization sinks in that the existing incident classification hierarchy is cumbersome and ineffective. Incident classification is important, so where is the best practice?