5 Steps for starting with Continual Service Improvement (CSI)

CSI has been one of the five publications in the ITIL service lifecycle since the introduction of ITIL v3 in 2007. It’s now often quoted as the best place to start with ITIL. The longer you wait to add in the capability to improve things, the harder it is to start improving things. In my experience, it’s the same for adding anything new with ITIL – if you don’t do it while you are focused on adding new people, processes, and technology (most likely when you are implementing new ITSM technology) then the pressures of day-to-day operations will probably prevent it at a later date.

CSI Is Not About Perfection

Some articles you might read state that the reason for CSI is to reach perfection, but in my opinion this is not the case. Think about it: How can you improve on perfection? You can’t, and therefore CSI would cease to be continual once perfection is reached. Although I guess the definition of what perfection is could change over time.

Also I believe in the Pareto principle, which states that 80% of events come from 20% of the causes. So, for CSI, that 80% of improvement can come from 20% of the effort. Or, looking at it another way, you’ll need to put in four times the initial effort to get the final 20% of improvement – and I’m sure for some improvement opportunities this cost might outweigh the effort.

So What Is CSI and How Should I Get Started?

In many ways CSI is a mentality or a culture that seeks to improve the status quo. From an ITIL perspective, CSI can also be seen as a number of processes used to support the advancement of an IT organization – allowing it to define, measure, and monitor improvements, or conversely, the deterioration in services and processes.

The ITIL CSI book is as thick as the other four that cover the other 25 ITIL processes between them – so let’s assume there’s six per book. So no matter the size or maturity of your IT organization it’s easy to get overwhelmed by the amount of CSI content. If you do want to start, especially without reading hundreds of pages on how to do CSI, then try these five simple steps:

1. List. Write down what you’d like to improve now. You’ll probably think of many things that team members have thought of in the past, but haven’t had the time or inclination to address. At this stage you don’t need to talk about the “how” just the “what.” You may find it useful to create a continual improvement register on a spreadsheet to capture the improvement opportunities. I’d also recommend keeping it super-simple, as people are unlikely to add to the list if it takes a lot of time or effort.
2. Discuss. Once you have a few improvement suggestions, pick out something that looks like it may be a sizeable benefit from minimal effort – a “quick win” – and discuss with colleagues how you could accomplish the improvement. And also how you would measure the positive or negative impact of any changes you make. Once you’ve agreed that the selected improvement opportunity is the best one to address, worked out how to progress with it, and ascertained that improvement is viable, then it’s time to move on to the next stage.
3. Assess. You should already know how you’ll measure the impact of the improvement so it’s time to work out where you are now in relation to where you want to be in order to set a baseline. It’s also a good time to evaluate where you stand in relation to industry norms – you can do this by doing some research yourself, by hiring an external consultant, or you may find that your ITSM solution vendor shares benchmark information with its customers for free. You might find that something you thought you needed to improve on is, in comparison to industry norms, actually already pretty good. And that it doesn’t need improvement ahead of other improvement opportunities. It’s also a good time to ensure that your planned improvements are in line with the overall business strategy, as you’ll find it difficult to gain the necessary business buy-in, and funding, if there are no perceived benefits at a business level.
4. Go forth and… improve (sorry I couldn’t resist that). In my experience, it’s important to treat each improvement as a separate project. You don’t necessarily need to undertake one improvement at a time but be mindful that when it comes to assessing improvements you need to be able to see which improvements gave the best results. By doing this, you can then reassess your improvement selection process and criteria.
5. Reassess and Report. As you’ve collected your baseline data you can now assess both the negative and positive impacts your improvements are having. But don’t stop here – ensure that you share the great stuff you’re doing with the wider business; it’s another way to help raise the perceived value of the IT organization. I would, however, caution against reporting success in IT terms rather than business terms, or creating reports for the sake of reports – the business just won’t care.?Please remember though that this isn’t a beginning-to-end process. Continual service improvement should be just that – continual. Just because something has been improved once doesn’t mean it can’t be improved again. But as I mentioned in the Pareto principle section, don’t try to keep improving things just because you can – incident management is a good example, where we keep trying to get better at it and possibly ignore the opportunity that is problem management.

If you still feel daunted about CSI then just take one stage at a time, baby steps if you like. It’s easy to list possible improvements, and the possible benefits from just a few, seemingly small improvements, can be significant.

It might sound corny but CSI, as with many things in life, business, and ITIL is not about the destination, it’s about the journey.

Credits: joetheitguy.com (Check it out. Great insights)