5 simple steps for CSI

5 Simple Steps for Starting with Continual Service Improvement (CSI)

I was asked by my superiors, of which I have many, to write a blog about CSI. But for some reason SysAid’s content editor, the amazing Dena Wieder-Freiden, didn’t like what I’d written about dead bodies and forensics. Seems it was the other CSI – continual service improvement. Ah well, back to the day job…

CSI has been one of the five publications in the ITIL[1] service lifecycle since the introduction of ITIL v3 in 2007. It’s now often quoted as the best place to start with ITIL, instead of the late noughties’ advice of starting with incident and problem, incident and change, or change and configuration. And with good reason – the longer you don’t 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 (also known as the 80-20 rule, the law of the vital few, and the principle of factor sparsity), 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.

If you want to read more about CSI, then please take a look at my good friend Stuart Rance’s blog and white paper: The Help You Need to Adopt Continual Service Improvement.

Image credit

[1] The IT service management (ITSM) best practice framework.

Posted by Joe the IT Guy

Joe the IT Guy
Joe the IT Guy

Native New Yorker. Loves everything IT-related (and hugs). Passionate blogger and Twitter addict. Oh...and resident IT Guy at SysAid Technologies (almost forgot the day job!).

4 thoughts on “5 Simple Steps for Starting with Continual Service Improvement (CSI)”

  1. Avatar Bob

    Here are some questions and reasons behind these questions to ask:

    Given ITIL’s guidance have statements such as “Continual Service Improvement will require that key roles are filled for trend evaluation, analysis reporting and decision making. Process compliance is critical for ensuring that the proper output for process metrics is used for identifying process improvement initiatives.”, here are questions I recommend be asked before continual service improvement efforts begin formally:
    1. Regarding IT capabilities and costs:
    a. What documentation has been created communicating current understanding of IT capabilities? Has any ITSM playbook, business plan or training documentation been shared formally or informally? Are there any illustrations/diagrams of capabilities’ relationships, roles or responsibilities?
    b. What performance gaps have been defined? What efforts to bridge those performance gaps have succeeded or failed?
    c. What accounting documentation has been created communicating current understanding of IT costs? How are those costs measured, trended and used by decision makers? Have any decisions been made which costs were later not justified by ROI calculations?
    d. What opportunity costs are being incurred? (e.g., Is poor ITSM causing customer defections?; Are problems not being managed and therefore causing more incidents?)
    Purpose: We want to assure relevant ROIs and use objective measurements when planning, forecasting, etc.
    2. Regarding business drivers:
    a. What has been driving IT-related decision making? What can be learned/summarized from past decision making?
    b. Have such driving forces or key result areas (KRAs) been documented as goals, objectives, or anything else?
    c. Are intangible benefits over emphasized at the expense of tangible benefits?
    d. Is scope creep being avoided?
    Purpose: We want to know who/whom the champion(s) of ITSM is/are to encourage her/his/their leadership and support. We want to know who the critics of ITSM are to encourage fair feedback concerning failures and recognition of successful improvements.

    3. Regarding data, metrics, trending, etc.:
    a. Are measurements of customer satisfaction, first call resolution, cost of a Level 2-type support visit, etc. reliable and used to coach for improved personnel performance, plan staffing schedules, etc.? What measurable benefits are being trended and used to plan, forecast, negotiate, etc.?
    b. Are measurement frameworks (beyond simple component/system measurement) being used to plan, justify decisions, etc.?
    c. How do executive leaders measure success? What are their success criteria? It ITSM’s work being measured in ways which will inform and persuade executives to fund ITSM?
    d. Has the Pareto Principle (aka 80/20 rule) been applied to ITSM work? What 20% of software and hardware cause 80% of incidents? What 20% of staff necessitate 80% of tickets created? What 20% of help desk staff have great first call resolution rates? Are they being rewarded? What 20% of help desk staff cause 80% of ticket escalations? Are they being coached to improve their work performance?
    e. Can we progressively measure and monitor ITSM’s benefits/returns?
    Purpose: We want to advance process maturity in data-rich environment.
    4. Regarding IT downtime:
    a. Are costs of IT downtime to the business being measured? Can cost measurements be trended over time? Is such documentation used to justify redundancy of equipment and implementations of other best practices?
    b. Has a detailed history of downtimes’ descriptions been maintained as reference documentation?
    Purpose: We want to know what investing in ITSM helps us avoid and use such details to justify IT investments.
    5. Regarding knowledge of ITSM at each level of the organization:
    a. Are metrics such as cost of an incident, cost of a Level 2 support visit, etc. being trended and used in planning and other decision making?
    b. Do customers know why and how they should communicate incident, event, etc. needs to the help desk? Or do they avoid ticketing by complaining to their managers?
    Purpose: We want facts so communications, plans, etc. are accurate and we enable effective and efficient ITSM.
    6. Regarding drafting and communicating a clear and persuasive case for process improvement as a formal business function:
    a. Are there examples of successful process improvements in the past? How well are those successes documented? Are such successes well known by staff and used as good examples of quality improvement efforts?
    b. What documentation has been circulated concerning quality improvement efforts in the past? How well was it received and used? Should it be re-purposed now?
    Purpose: We want ITSM done in ways which support customers’ needs and help them help their customers succeed.

    7. Regarding ITSM methods:
    a. Is any non-IT department using any form of formal process improvement (e.g., PDCA)? How likely is it that the organization’s culture will welcome and support the seven-step improvement process recommended by ITIL?
    b. Is incident management being performed in ways which contribute to successful problem management and avoidance of unnecessary rework?
    c. Are events treated as incidents instead of planned/budgeted activities? If so, what should be done to make sure events are not treated as incidents?
    Purpose: We want the benefits of event, incident and problem management.
    Answers and reactions to these questions should aid in negotiating plans, improving programs, lowering some ITSM costs, etc. to face challenges associated with achieving measurable desired outcomes after adopting standard and consistent approaches.


  2. Avatar Bob Davis

    Is working to improve first call resolution (FCR) measurement and trending (while preserving or improving customer satisfaction ratings) the best place to start using ITIL’s CSI? If you agree, is working to improve the 20% of support agents who produce 80% of FCR failures the best group to target with a common performance improvement plan?


    1. Avatar Joe The IT Guy

      The best place to start CSI is focusing improvement activity on what is most important to end users and business stakeholders – so ask them. For example, FCR might not be that important if it keeps the end user on the phone for 45 minutes as the service desk agent feels compelled to deliver an FCR. With the alternative a quick capture of the issue and a call back in 20 minutes with a “second contact resolution.” End users might instead prefer to be treated more like customers (or at least people over asset numbers), with the required improvement in service desk agent approaches and skill sets, rather than being able to get a quick but poorly executed resolution via FCR. There might also be ways that help all agents, no matter their current performance, such as better knowledge management (and exploitation) on the service desk … and let’s not forget that end-user facing knowledge articles and self-service capabilities will probably cause FCR to drop as the simpler issues (to resolve) no longer hit the service desk. Finally, whether CSI activity is focused on FCR or elsewhere, you will need to ensure that agent performance metrics aren’t skewed by things such as senior personnel cherry picking the easiest to resolve tickets versus newer staff getting the more complex ones. In doing so they set an expectation of FCR that probably isn’t achievable across all incident types.


Leave a Reply

Your email address will not be published.