ITIL v3 and the Rebel Without a Root Cause

by Martin McEvoy | 25 Jun 2007 | Permalink | Featured, IT Management

Is your infrastructure behaving like a rebellious teenager and if so will ITIL v3 help??

The five core ITIL v3 publications were published on 30^th May 07. The five titles forming the core of ITIL practice are:· Service Strategy · Service Design · Service Transition · Service Operation · Continual Service Improvement. These will replace the old ITL v2 core books titled Service Support and Service Delivery. Future v3 stages will release a range of complementary guidance that supports the practices in the core books.

I was personally never comfortable with the v2 Service Support/ Service Delivery split. I thought it was confusing and caused a divide between the two sets of processes. But more importantly v2 missed the earlier life cycle stage of developing service. Within IT there is generally a lack of understanding around the practice of service development and v2 didn’t help. I have even seen large outsource deals skim over this vital deliverable and IT Managers left wondering why service levels are so poor after the service goes live. In these cases service gets painfully developed after go-live, through a series of problems and outages.

I think the lack of service development best practice is also partially the reason why many organisations have struggled to implement their ITIL solutions. If you think about it, this is just service development at an organisation level. Many approaches have lacked completeness of strategy and design, using ITIL projects to force process changes into a live operational organisation. An ITIL implementation should be managed as an organisation change, not a project. So like the outsource example service gets developed in live mode, in a lengthy series of process and tool changes. The disruption this causes often leads to disillusionment and decays believe in ITIL.Without a structured service management solution organisations force projects to develop their own service solutions. At its crudest this has taken the form of a specialised helpdesk for the new service and perhaps a specialist team of support staff and developers. So rather than integrate the new service into the live operational service an additional organisation is formed. This of course is expensive and ultimately unsustainable, but there is little option if the live operational service is disorganised. The irony is these new mini organisations only add to the disorganisation. 

For those who achieved it, v2 was good at providing a framework to manage service operations. It helped reduce the pain caused by projects “throwing stuff over the wall”. By providing a framework for operations it gave projects a structure to deliver into, removing the need to invent their own service solutions. But they still needed to invent the service development approach which leads to inconsistencies and omissions.

From what I can see, v3 goes a long way to address the service development gap. With the introduction of Service Strategy, Service Design and Service Transition the life cycle is complete. So service is developed in strategy and design progressing into the live state in operations via service transition. It goes as far to recommend a new organisation for service transition.

By looking after our CIs from the very beginning of their life we can expect them to behave better when they are released in to production. We can also expect the production environment to be ready for this transition. Once in production the nurturing should continue to ensure the CIs grow safely in to old age and beyond.

How many rebels do you have in your data center and have you managed to eliminate the root cause of the problem???