Developing the business case

Business people working together A recent survey by the IT Service Management Forum, itSMF, of over 2,600 service projects in 550 different companies returned some surprising results. Over 75 per cent of these projects were completed in order to improve customer service, and yet only 12 per cent of them had yielded any form of financial benefit.

Peter Wheatcroft, Partners in IT, describes the context within which a business case should be presented and goes on to explain that less tangible aspects make good business sense - including superior service propositions to make it easy for customers to engage.

Not all projects will show a financial return, although it could be argued that the cost of poor service will lead to loss of custom and therefore addressing this concern will show a benefit - but the organisations, concerned in this survey, did not generally take this into account in their submissions. 

Many of these service improvement projects were felt to have some financial justification, although there was little or no evidence provided of a detailed, robust or consistent return on investment (ROI) process to demonstrate the value. Despite this, measurement of the value derived from these projects was seen to be important in 37 per cent of the companies surveyed. 

The techniques of investment appraisal have long been used in IT to evaluate the business benefits of spend on development projects, which are mostly regarded as value-adding but usually discretionary in nature.

However, such techniques are rarely applied by IT services departments because the linkage between investment levels, return on investment (ROI) and the ongoing cost of delivery has not been properly articulated. This is a pity, because the benefits of formal appraisal will often yield as much value from careful investment in service capability as it will from yet another new product system. 

Many service improvement projects start off with an emphasis on the service, or helpdesk.  Whilst this is understandable as the helpdesk is the most visible part of the IT department, this emphasis can easily become introspective.

Service desk operations are frequently run like a manufacturing production line, concentrating on call handling statistics such as time to answer and call throughput, which leads to IT management regarding themselves as good performers when such targets are met. 

However, when customers of those IT service providers are asked about their experience of IT, there is often a different story - they feel the organisation is not solving the underlying problems and resent having to ring the help desk, even if they did admit the responsiveness was good.

Quality of service (QoS) should be measured by customer metrics such as ease of use or satisfaction figures rather than IT operational statistics and this is a better way of determining service value than an SLA report. QoS can also be described by the absence of outages, problem avoidance and the elimination of waste and inefficiency for the customer.

By concentrating on the customer benefit of service, the value to be gained from a service improvement programme can be determined before the cost it will take to deliver it, reversing the normal course of investment thinking which often puts budget before benefit. 

The following example illustrates how, by using a technique like Six Sigma, the customer benefits can be defined before any work is done on the costs to implement a solution.

Case study based on Six Sigma

This example is taken from work done for a major international retailer of travel tickets. The company sold tickets for travel through an on-line ordering system based on a browser interface on their website and then through a number of internal systems linking to a complex revenue management algorithm that decided what to charge for tickets depending on time of day, volume of tickets sold, number of seats available and other pricing strategies such as special promotions. 

As the system was available to any customer in the world, it had a true 24x7 availability requirement but the business case for investing in a higher level of availability than was being achieved was hard for IT to justify. Interviews were arranged with the business owners of this service to discover the value of each sale, the opportunity loss of each failed sale and the likely volume of sales each year. This voice of the customer (VOC) exercise revealed a number of important characteristics:

  • the loss of ticket sales was irreversible - customers simply went elsewhere if the on-line booking service was unavailable;
  • service costs were predicated on a project budget and not on service value;
  • the order taking system generated £250/min sales revenue.

So based on this, the following analysis was carried out:

Uptime Service downtime
Actual SLA attainment: 99.5%  43¾ hours/ year
Best practice level: 99.995% 26¼ minutes/ year

                                                       
As every order missed is deemed to be irretrievable, the loss of income was:

Service downtime Loss of income
Actual SLA attainment: 43¾ hours/ year                 £650,430
Best practice level: 26¼ minutes/ year             £6,570

The margin made on each ticket was 20 per cent, so the actual loss to bottom line profitability from a loss of income of nearly £650,000 a year was £128,772.

This level of benefit justified a re-engineering exercise to increase the overall availability from 99.5% to 99.995%, nearly sigma level 6, which was the level agreed as being achievable, with payback of the costs within one year. This resulted in a better service, a happier customer and an IT department which needed to do less fire fighting and that now knew the business value of its service. 

This example shows what holistic analysis can achieve in terms of service value and that is not all Six Sigma can be used for. However, as a way of producing a result that makes sense to the customer, a business case for service improvement is far easier to construct than just concentrating on production line figures. 

May 2009