SIP Talk!

So you want to create a Service Improvement Plan document.  In order for me to discuss this topic, I would like to clarify couple of terminologies within the framework of ITIL. I would like to first describe the words Continual vs. Continuous.

‘Continuous’ is the stronger word, and it means that the continuity or union of parts is absolute and uninterrupted; like, a continuous sheet of ice; a continuous flow of water.  ‘Continual’, in most cases, marks a close and unbroken succession of things, rather than absolute continuity. So we talk about continual showers, we imply a repetition with occasional interruptions.

So in an IT organization most likely we will not be ‘continuously’ improving seamlessly, but rather it will be cyclical in nature; meaning there will be a period of stability followed by more improvements, then a new level of stability followed by more improvements and so on.

Once this point is clarified, to have a Continual Service Improvement initiative (CSI), you would need a Service Improvement Plan (SIP) for that particular account/customer.  This is providing that all components of the account are set prior to this, such as OLAs, SLAs, and UPCs. (Under Pinning Contracts).

Perception will play a key role in determining the success of any Continual Service Improvement initiative. It is important to understand where we have differences in perception between the customer and vendor.

Service Level Management has the task of ensuring that potential gaps are managed and that when there is a gap, to identify if there is a need for a Service Improvement Plan (SIP). Often a large gap exists between what the customer wants, what they actually need, and what they are willing to pay for. Add to this the fact that IT will often try to define and deliver what they ‘think’ the customer wants. As a result, it is not surprising that there is a perception and delivery gap between the Customer and IT.

There are four commonly used terms when discussing service improvement outcomes:

·        Improvements

·        Benefits

·        ROI (Return on Investment)

·        VOI (Value on Investment).

Much of the anxiety and confusion surrounding IT process improvement initiatives can be traced to the misuse of these terms that I just mentioned.

Here are some terms defined as per ITIL v3 and I will just quote these definitions for you:

Improvements – Outcomes that when compared to the ‘before’ state, show a measurable increase in a desirable metric or decrease in an undesirable metric.

Example: Say the vendor achieves a 15% reduction in failed changes through implementation of a formal Change Management process.

Benefits – The gains achieved through realization of improvements, usually but not always expressed in monetary terms.

Example: Vendor achieving 15% reduction in failed changes has saved the company $395,000 in productivity and incident costs in the first year.

ROI – The difference between the benefit (saving) achieved and the amount used to achieve that benefit, expressed as a percentage.

Logically, one would like to spend a little to save a lot. Example: If the vendor spent $200,000 to establish the formal Change Management process that saved $395,000. The ROI at the end of the first year of operation would be $195,000 or 97.5%.

VOI – The extra value created by establishment of benefits that include non-monetary or long-term outcomes. ROI is a subcomponent of VOI.

Example: Vendor’s establishment of a formal Change Management process (which reduced the number of failed changes) improves the ability of the vendor to respond quickly to changing market conditions and unexpected opportunities resulting in an enhanced market position. In addition, it promoted collaboration between business units and the organization and freed up resources to work on other projects that otherwise may not have been completed.

VOI attempts to capture value that lies beyond the reach of an ROI calculation like:

·        Increased organizational competency

·        Integration between people and processes

·        Reduction of redundancy to increase business throughput

·        Minimized lost opportunities

·        Assured regulatory compliance that will minimize costs and reduce risks

·        Ability to react to change rapidly.

So understanding the Vendor’s target and current situation should form the basis of the Business Case for a SIP. You can usually do a stakeholder analysis and a goal setting exercise to help focus on your future results and aims.

A Service Improvement Plan (SIP), just like any other major plan, will have costs associated with executing its activities. Things like:

·        Staff resources trained in the right skill sets to support ITSM processes

·        Tools for monitoring, gathering, processing, analyzing and presenting data

·        Ongoing internal/external assessments or benchmarking studies

·        Service improvements either to services or service management process

·        Management of time to review, recommend and monitor CSI progress

·        Communication and awareness campaigns to change behaviours and ultimately culture

·        Training and development on CSI activities; just to name a few.

SO before you start your SIP, you need to make sure that you are backed by those who can help you achieve the changes that need to happen within the process.

Once you have worked to identify the service gaps and have done the data collection and suggestions, now is the time to follow up on the issues and see them to completion; some of which of course you may find that are already being worked on. 

To be effective, CSI requires open and honest feedback from IT staff. Debriefings, or activity reviews, work well for capturing information about lessons learned like ‘did we meet the timelines?’ and ‘did we provide quality? Etc. Segmenting the debriefing or review into smaller, individual activities completed within each phase of the service lifecycle and capturing the lessons learned within that phase makes the overabundance of data more manageable. Collecting this information is a positive beginning toward facilitating future improvements.  So you would need to create a “Control Loop” so to speak. 

Just to give you a quick overview of a Control Loop:

I have used the Monitor-Control Loop. The loop consists of a set of steps that produces feedback to help improve individual process steps, the process as a whole, the stages of the lifecycle and the lifecycle as a whole.

So I usually start the loop by conducting an individual process step, by taking inputs and creating outputs. While conducting the step, I monitor the activity and the output. Monitoring involves observing the activity and gathering data about the step or output.

Then I compare the data against an established norm. The norm can come from the targets that you have in the Service Level Agreements and in the Critical Success Factors (CSF) and Key Performance Indicators (KPI) determined for the process.

Then I control the process by making improvements or changes to the way I conduct the activity and continue to monitor the results.

Monitor-Control Loops provide a simple and effective way of ensuring that your processes are delivering on the promises you have made to the customer and users in terms of value.

So the SIP document basically contains most parts that I have explained here such as gap analysis, data gathering and improvement suggestions; except the implementation and the control loop.  For the control part I further create spreadsheets that monitor the performance of SLAs and the follow ups that happen on a monthly basis with the IT staff involved.  The process of creating a SIP and following up on it theoretically is a 1,2,3 step, but when you actually pull your sleeves up and start asking questions it can be lengthy and sometimes even derailing from where you were going originally so it is good to keep your focus on the main issue and perhaps create side projects from whatever else that pops up.

Hope this has been of some use to you.  Thanks for reading.