This the third part in a series of considering ITIL core problems.
Version 3 brought us the service lifecycle in two senses:
- the service portfolio followed the lifecycle of services with future services and removed services
- the core books were organized around the lifecycle
The concept of new services was a welcome addition to ITIL, former versions considered a more or less static IT operation with no guidance on introducing new elements to it. But the realization of the lifecycle concept was not successful. There are three reasons to scrap the lifecycle:
1) The concept of service is difficult to apply
The definition of service was unfortunate. A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.
How does internal IT release the customers from the ownership of costs and risks? This clearly defines services like renting a facility but not IT services. The concept of IT as a service is useful. It is good if the server administrators understand that instead of administering servers they are providing a service to the business. All IT work is a service to the parent organization. But the concept of service is elusive. The server admin provides services which the customers do not understand. It is common that business units are more involved in their own applications. In some cases business units buy directly the application services they need. This is healthy; the business unit knows better what it wants than the corporate IT. The problem is that the concept of service becomes cloudy. The end-to-end service can comprise several components which are not under single management. There is a value chain or network with several players. There is a difference between understanding that IT is a service and defining IT services.
Experience shows that Service Level Agreements are often less valuable than they were expected to be. Especially an internal IT should consider other options than a Service Catalogue as their interface to business. Capabilities are important and a capability is not the same as service. IT customers do not want the services, but they want the outcomes those services provide.
2) IT does not own the lifecycle
The concept of an IT team deciding on the strategy and lifecycle of IT services is unhealthy. Most of the IT services are business services which are supported by IT systems. IT does not own the business services and cannot plan their lifecycle. IT may plan to move from Windows XP to Windows 8 but that is not the end of XP lifecycle, it is just a new version of the laptop service. Business might decide to replace laptops with tablets and that might be the end of the laptop service. Instead of planning lifecycles for services, IT should be planning for different scenarios and alternative solutions.
3) The lifecycle provides a clumsy structure for the material
Third reason to scrap the service lifecycle is that it does not provide a good structure for the ITIL books. The original Service Support – Service Design was actually better. The new ITIL structure should be based on audience. These could be:
- daily operations and the Service Desk for operations staff
- availability and continuity planning for operations planning
- application management for applications teams
- relationship management, planning and improvement for IT management
All material should be considered from internal and external point of view. There should be a module for Service Integration.
This was the third part of the series on improving ITIL. The key points were:
1) Forget the service lifecycle, it is not a good way to present the framework.
2) Remove most of the processes, and describe them as activities. The key points are the value of the activity, not the mechanics of it.
3) Fix the core processes and the terminology.