Managing a continual service improvement register
Last month I wrote a blog about reviewing your management system, which ended by saying:
“After you’ve identified a few improvements you want to make it’s a good idea to document these somewhere. Write them all down in one place and you’ve got a continual improvement register! There’s no need to make a big deal of ideas like a continual improvement register. I have seen organizations spend weeks designing one, but you just need to let it evolve as you discover new things you want to record.”
So in this blog I’m going to write about how to manage your continual service improvement register.
How to populate a CSI register
Let’s start by thinking about how to identify improvements that are needed. In my previous blog I discussed the value of carrying out an assessment, which is a great way to identify things to go on the CSI register. There are lots of other things you can do that will also identify improvement opportunities:
- Review customer feedback and complaints
- Ask customers to suggest improvement opportunities
- Make time in regular customer review meetings to discuss what improvements they would like to see
- Review service reports for trends and issues that need to be addressed
- Ask IT staff for improvement suggestions
- Ask development and project management staff for improvement suggestions
- Review risk registers to see if there are any improvement opportunities there
- Look at process KPIs and any internal process assessments
- Review problem management records
- And of course regular IT service management reviews, to identify what’s going well and what’s going badly
What information do you need for each opportunity on the CSI register?
As you capture each opportunity into your CSI register you’ll need a bit of information about it, to help you prioritize and manage the opportunities. Try not to make the CSI register too complex though, I just use a simple spreadsheet with columns for:
- ID – give each improvement opportunity a unique ID
- Description – what improvement is needed
- Benefits – why this improvement is needed. Ideally this will be in terms of benefits to end customers, but benefits to the IT organization should also be noted, It is also worth scoring the benefits on a simple High/Medium/Low scale, to help with prioritization
- Urgency – when this improvement is needed. Sometimes there will be a real time constraint (before a particular business event) other times the urgency may be based on how long before a trend causes a target to be missed, or how much money is being lost. A simple High/Medium/Low is often sufficient for the urgency.
- Time – how long it will take to implement this improvement. A rough estimate is usually sufficient at this stage. Will it be a few weeks, a few months or many years?
- Cost – how expensive will this improvement be. You won’t have details at the time you log the opportunity, but you should be able to identify whether the cost will be High, Medium or Low
- Owner – who is going to own this opportunity, to carry out any further analysis and help decide whether to proceed with it? Often this will be the person who logged the opportunity but it may be someone with expertise in the specific area, such as a service owner or information security manager
- Date submitted – so you can see how long the opportunity has been on the register
- Status – to track what has happened to this opportunity. I usually restrict this field to a set of fixed values that represent the lifecycle of an opportunity (Logged / Under Review / Rejected / Approved / Ongoing / Complete / Closed or something very similar)
- Percent complete – I use this with a status of “ongoing” for improvements that take a long time to implement
Some people include other fields such as Risk (how likely is this to go wrong) and Status text (a free text field to provide more detail of status updates).
How do you decide which opportunities to follow up and which to ignore?
After you have filled in the CSI register it is surprisingly easy to identify which opportunities you want to invest in. You could define formal rules for this, but I usually find that it is so obvious that this is not necessary.
- Start by looking for improvement opportunities with High benefit, High urgency and Low cost and just assign these to someone for design and implementation
- Opportunities with High benefit, High urgency and Medium or High cost will need a proper business case to justify the funding. Again you should assign these to someone who can create a business case which you will take to the business for approval.
- Opportunities with Low benefit and High cost can usually be rejected without further consideration.
- The remaining opportunities can be ranked by benefit, cost and urgency to enable you to select the most worthwhile
Don’t try to start too many improvements at once, it’s better to start a few improvements and invest the resources needed to complete them fairly quickly than to take on too much and see things stall and fail to make progress. If you are familiar with the Theory of Constraints, or use of Kanban to manage work in progress then you should recognize the value of limiting the number of things you try to do at the same time.
If you are familiar with the use of Agile then you may want to treat the CSI register as a backlog. This combination of Agile and IT Service Management can be very effective at helping you to realize continual incremental improvements in the services you deliver to your customers.
How should you manage the improvements?
There is no single correct way to manage the improvements, but it is important to make sure that every improvement that you initiate does deliver the value that you expect.
If you have a preferred method for managing small projects then you should use this, whatever it is, as it is more important to be consistent and to know what you’re doing than to achieve some artificial idea of perfection. If you are familiar with agile then I strongly recommend using an agile approach to managing CSI. The combination works very well to deliver real improvements in regular increments.
Whatever approach you use it is important to hold a review at the end of each improvement activity. If you are using agile then this is the retrospective, if you are using a project management methodology then it should include a post implementation review. In any event this review is an important part of CSI, and it will often identify further improvements that you can add to the CSI register. The review should not just confirm that you implemented the planned improvement, but it should try to quantify the actual business value that the improvement has delivered. This information should be captured on the CSI register, so that you can understand the value of CSI and report this to the business.
Separately to the management of each improvement activity, you should manage the CSI register itself as a portfolio of improvement opportunities. This means that you should track the expected cost and benefits of each improvement, and compare these to the actual cost and benefits that it delivered. You should make sure that the people funding your continual improvement understand the value this has delivered, as this will often lead to increased funding to allow you to make further improvements.