Continual service improvement (CSI) has unfortunately been a long-neglected area in IT service management (ITSM), sometimes viewed as the ultimate post-success undertaking (“We’ll get to that once all of the planned work has been completed” – which is shorthand for “never”). With the publication of ITIL Practitioner, CSI as crucial capability has become significantly more prominent, but the results could often be better. This blog explains why and what to do about it.
Common Issues with CSI
An improvement initiative in ITSM can be either an introduction of something new – a service, a process, a procedure, a metric, an automation capability, etc. – or changing what’s already there. For most organizations, thinking about improvements is not a ‘greenfield’ exercise – there are many existing components that need to be taken into account and starting from scratch is not an option. To be fair, ignoring what’s already there would also go against one of the 9 ITIL Guiding Principles – ‘Start where you are.’
In everyday situations, improvement work often competes with ‘normal’ work – both planned and unplanned. The more often a team finds itself in a fire-fighting mode, the less likely it is for them to find the time to assess potential improvement initiatives. The feeling of constant work overload becomes the norm, and the main effort goes to keeping their heads above water.
When the team does get a break – perhaps because everybody else is on holiday – and one of the now-already-faded Post-It Notes with an improvement idea is cleared of dust, the results of carrying out that improvement are often not what was expected. Not because the execution was flawed – the end state does roughly match the expectations – but because the customers don’t seem to be happier. In fact, it seems as if they don’t care at all – and all that extra hard work might have been wasted.
The Adverse Impact of “Failed” CSI Efforts
It would be great to be able to comfort you and reassure that of course the effort was not in vain, and eventually the praise will find its way to the team. In reality, that is a very unlikely scenario. The praise will not come, and the team has just created more problems for themselves – a hit on motivation and the customer being even more skeptical about the value of the work done in ITSM.
In many organizations, this cycle has resulted in widespread apathy, significant resistance to improvement initiatives of any kind, and a high employee churn rate. Together with the way-too-common lack of maturity in knowledge management, the ever-changing faces in IT (with limited knowledge of the customers’ history) kick off yet another cycle of skepticism and questioning of (IT’s) value. This double loop of failure is hurting the whole organization, not just IT.
A Common Root Cause of “Failed” CSI Efforts
One of the common reasons for failed improvement initiatives – where the effort is put in, time and money is spent, but the customer couldn’t care less – is that the results are either invisible or unclear for the customer. Yes, a more efficient process is likely to cut down costs in the long run; yes, investing in an automation tool frees people’s time up to work on more complicated issues; and yes, improving the call resolution time means spending less time away from daily tasks for the users. The problem is that many of the improvement attempts in ITSM, and IT in general, look at technical, not business, metrics. The improvement in the efficiency and/or effectiveness of something is demonstrated for the service provider, not the customer. The value is (hopefully) delivered by proxy, but that is not enough!
The internally focused view and messaging of improvements can easily lead to a decrease in observed value, rather than the expected increase. Why was the process that’s now being improved designed badly in the first place? Why do we have so much repeating work in IT that we need to invest in automation – can we not just fix it once and for all? Why do we have to spend any time talking to IT support – can’t they build a system that just works? Why do we need to keep giving money to the department that clearly doesn’t know what they are doing?
What to Do (to Improve the Outcomes of CSI)
Instead of proposing and then celebrating the increase in efficiency and/or effectiveness for us, the service provider, we need to express the effects of the improvement in the language of the business, and as value for the organization. We need to take a hard look at whether we’re making things better for us, or for the customer. Every department in the organization is constantly changing the way they work, IT is no exception. How many of those other departments justify their plans with: “It would make life so much easier for us, and maybe somehow also for you, thank you very much”?
The role of technology in supporting the whole organization and giving it a competitive edge is increasing rapidly. IT is no longer an order-taker, it’s a business enabler. The chance for the IT organization to be a major contributor to growing the business and better serving its customers is here – but to be understood and supported, we need to change the language we speak. We need to move away from celebrating outputs that are defined in IT terms, to working with the rest of the organization to align around the objectives and achieve the outcomes needed. What we do is very important – but we need to become much better at explaining why it’s important for the whole organization, not just us. This applies to CSI just as much as any other IT activity; and it’s only through taking this approach that CSI efforts and results will be truly valued.
