ITIL framework has provisioned a complete set of activities for improving services across all the phases of ITIL service lifecycle. The continual service improvement (CSI) lifecycle phases stretches across other phases, and improvements can be called out and implemented in any of the phases, and at any point in time. This is the principle behind setting up service improvement as a phase and running it across other phases.
The CSI phase leverages the 7-step improvement process to identify and deploy improvements. But my experience is that the process is rather cumbersome and could be done away with, for a lite version that I am about to discuss in this series.
We are in an agile world today. Meaning, we need things to move quickly rather than getting stuck onto inputs and comparisons. We need to adapt to the quick turnaround expectations of the business and take out all the possible flab to ensure that the improvement process itself is lean and iterations can be run in a minimal fashion.
The 7-step improvement process is like the project management waterfall methodology. It has pre-conceived steps that can only be executed in a sequence. The following are the sequencing of activities for the process:
- What you should measure
- What can you measure
- Gather the data
- Process the data
- Analyze the data
- Present the information
- Implement corrective action
Holistically, the process looks logical and it makes sense. But realistically…
Before you get to analyzing the available data, you would have missed the train in terms of keeping up with the freshness of the data, and the relevance of it all. Data keeps accumulating and it needs to be processed in a timely fashion. This is only possible if you can have a framework for improvements that runs alongside you.
You could argue that steps 1 and 2 are a one-time activity and steps 3 and 4 are necessary to analyze the data. Think again! Requirements and expectations change in the direction of the wind, and there is no telling how long a particular orientation is going to stick. So, how can we confidently say that steps 1 and 2 is done once. It probably needs to be redone every time the expectations change and when the purview of data analysis change. A good example is a telecom operator, who needs to change his business tack in line with the competitors, government regulations and innovations coming from the R&D activities.
Steps 3 and 4 are usually automated as we cannot afford to gather and process the data anymore. The activity does not require human intervention in pulling data from various sources, and processing it for standardization, consistency and to ease data analysis. It can all be scripted and put on a cron job for timely delivery of data in a pre-conceived location.
Today, analysis of data is automated as well. This is true in the case of mundane analysis requirements that is triggered by contractual obligations. Those looking for speedy improvements and on-the-fly deployments don’t trust automated analysis but rather would get their hands dirty.
Steps 6 and 7 are fairly standard, even to the agile nerds.
To sum it up, if you are in a fast paced industry like telecom, then you need something better and agile than the 7-step improvement process. If you are in banking or sluggish paced industries, probably this ITIL process is relevant. Even then, why would you sacrifice speed and productivity when you are set to gain nothing? Let’s explore throughout the series and see how my lite version of the process makes a whole lot more sense!