Managing a continual service improvement register

By Stuart Rance on 29 Baronial 2014 in ITSM, CSI, Agile

Last month I wrote a blog nearly reviewing your direction organization, which ended by saying:

"After you've identified a few improvements you want to brand it's a good idea to certificate these somewhere. Write them all down in one place and you've got a continual improvement register! There's no demand to make a big deal of ideas like a continual improvement register. I have seen organizations spend weeks designing one, but you merely need to let it evolve as you discover new things you want to record."

So in this web log I'm going to write about how to manage your continual service improvement register.

2014 08 29 Managing a continual improvement register IMAGE

How to populate a CSI register

Allow's start past thinking about how to identify improvements that are needed. In my previous weblog I discussed the value of conveying out an cess, which is a groovy mode to identify things to get on the CSI register. There are lots of other things you tin can do that volition also place improvement opportunities:

  • Review customer feedback and complaints
  • Inquire customers to propose improvement opportunities
  • Make time in regular customer review meetings to discuss what improvements they would like to see
  • Review service reports for trends and bug that need to exist addressed
  • Ask IT staff for improvement suggestions
  • Ask development and project direction staff for improvement suggestions
  • Review risk registers to run into if there are any comeback opportunities there
  • Look at process KPIs and any internal process assessments
  • Review problem management records
  • And of class regular Information technology service management reviews, to place what'due south going well and what's going badly

What information do you demand for each opportunity on the CSI register?

As yous capture each opportunity into your CSI register you'll need a bit of information about it, to help you lot prioritize and manage the opportunities. Effort non to brand the CSI register besides complex though, I just employ a simple spreadsheet with columns for:

  • ID – give each comeback opportunity a unique ID
  • Description – what improvement is needed
  • Benefits – why this comeback is needed. Ideally this will be in terms of benefits to end customers, but benefits to the IT system should also be noted, It is also worth scoring the benefits on a simple High/Medium/Low calibration, to help with prioritization
  • Urgency – when this improvement is needed. Sometimes at that place volition exist a real time constraint (before a particular business event) other times the urgency may be based on how long before a tendency causes a target to be missed, or how much money is being lost. A unproblematic Loftier/Medium/Low is often sufficient for the urgency.
  • Time – how long it will take to implement this improvement. A rough estimate is ordinarily sufficient at this stage. Will it be a few weeks, a few months or many years?
  • Cost – how expensive volition this improvement be. Y'all won't accept details at the time you log the opportunity, just you should exist able to identify whether the cost will be High, Medium or Low
  • Owner – who is going to own this opportunity, to carry out any farther analysis and help determine whether to continue with information technology? Often this will exist the person who logged the opportunity but it may be someone with expertise in the specific surface area, such every bit a service owner or information security manager
  • Date submitted – so you lot tin run into how long the opportunity has been on the register
  • Status – to track what has happened to this opportunity. I commonly restrict this field to a set of fixed values that stand for the lifecycle of an opportunity (Logged / Under Review / Rejected / Approved / Ongoing / Complete / Closed or something very like)
  • 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 incorrect) and Status text (a gratuitous text field to provide more than detail of condition updates).

How do yous decide which opportunities to follow up and which to ignore?

Later on y'all have filled in the CSI register it is surprisingly easy to identify which opportunities you want to invest in. You could ascertain formal rules for this, only I unremarkably find that it is so obvious that this is non necessary.

  • Offset by looking for improvement opportunities with High benefit, High urgency and Low price and but assign these to someone for blueprint and implementation
  • Opportunities with High benefit, High urgency and Medium or Loftier cost volition need a proper concern instance to justify the funding. Over again y'all should assign these to someone who can create a business case which you volition have to the concern for approving.
  • Opportunities with Low benefit and Loftier toll can usually exist rejected without farther consideration.
  • The remaining opportunities can exist ranked by benefit, toll and urgency to enable yous to select the nigh worthwhile

Don't try to kickoff too many improvements at once, it's improve to start a few improvements and invest the resources needed to complete them fairly chop-chop than to accept on also much and see things stall and fail to make progress. If y'all are familiar with the Theory of Constraints, or use of Kanban to manage piece of work in progress then you lot should recognize the value of limiting the number of things you endeavour to exercise at the same time.

If you are familiar with the apply of Agile then you may want to treat the CSI register every bit a backlog. This combination of Agile and Information technology Service Management can be very effective at helping y'all to realize continual incremental improvements in the services you deliver to your customers.

How should y'all manage the improvements?

There is no single correct mode to manage the improvements, simply it is important to brand sure that every improvement that you initiate does evangelize the value that yous expect.

If you take a preferred method for managing small projects and then you should use this, any it is, as it is more of import to be consistent and to know what you're doing than to achieve some artificial idea of perfection. If you are familiar with active then I strongly recommend using an agile approach to managing CSI. The combination works very well to deliver real improvements in regular increments.

Whatsoever approach you employ it is important to agree a review at the end of each comeback activeness. If you lot are using agile so this is the retrospective, if you are using a project direction methodology then it should include a post implementation review. In any event this review is an important function of CSI, and it will oft identify further improvements that you tin can add to the CSI register. The review should not just confirm that you implemented the planned improvement, just information technology should try to quantify the actual business value that the improvement has delivered. This data should be captured on the CSI register, so that you tin understand the value of CSI and written report this to the business.

Separately to the management of each improvement action, yous should manage the CSI register itself as a portfolio of improvement opportunities. This means that y'all should rail the expected cost and benefits of each comeback, and compare these to the actual cost and benefits that information technology delivered. Y'all should make sure that the people funding your continual improvement understand the value this has delivered, as this will ofttimes pb to increased funding to allow you to make farther improvements.

Image credit: https://www.flickr.com/photos/61423903@N06/7382239368/in/photostream/