Why Service Level Agreements (SLAs) don't work

Don't get hog tied by cowboys

Why User Needs are not included in most SLA's, and how to get them included.

"quis custodiet ipsos custodes?" who shall guard the watchman?
Outsourcing-users home

There is a great deal of advice on the web about how to get your Service Level Agreement (SLA) right. Much of this is good advice, and - given the failure rate of outsourcing agreements - much of it is needed. However, even if good conventional advice is followed, there is still an excellent chance of dissatisfaction and frustration with the agreement. This page outlines why it is that so many SLA's fail the users they are there to support. Fixing SLA's is not hard if you take Human Centred Design (HCD) seriously and build it into the contractual arrangements. Outsourcing-users.com can help you do this.

Some problems are given here under the following headings:

The creation of an SLA

The point at which an SLA is put creates a boundary. Where there was flow, there is an interruption. Where there was flexibility, there is rigidity. Where there was informal knowledge transfer and shared responsibility,there is a contract. Look before you leap.

Who writes the SLA?

The customer could choose to use a standard agreement from the supplier, but it must be fairly clear that this will favour the supplier.

He could write one himself - but who is going to do it? In the case of IT or BP outsourcing, the people who understand what is being outsourced will either be working for the supplier or be getting paid off. They are unlikely to act in the customer's best interests. People from other parts of the customer organisation are very unlikely to understand the business being outsourced well-enough to write or even review an SLA.

Alternatively, the customer could bring in a consultant to write or review the SLA. This brings with it all the risk of asking someone who doesn't share the risk to decide how it is to be allocated.

All in all, it isn't likely to be easy. Without a workable answer to this question, the risks of outsourcing probably exceed the benefits.

Who monitors the SLA?

Almost always, the answer to this question is the outsourcing supplier, not the customer. No implications of impropriety are necessary for this arrangement to have huge disadvantages for the customer and the users of the service.

In some instances, the customer has agreed to SLA items that he cannot monitor. For example, in one large UK agreement, network transit time is a key parameter. How can the customer monitor this in an unbiased manner? If they decide to run a test, how can they know it is not sysop-assisted?

Being presented with a monthly report (along with a request for payment) is not the same thing as keeping your eye on the ball, and really understanding how the agreement is going. For example, the customer may be told how many times a 4 hour time limit was exceeded. What he won't notice is the implication of this reporting arrangement; once the limit has been exceeded, there is absolutely no incentive to ever get around to doing the task - it is written off. All the user (of the 'service') can do is to raise a fresh call and hope.

Definitions are likely to be in small print, and in the supplier's favour. to give an IT help desk example, when a call is deemed to have started is bound to be well after the problem first appeared and may well be long after the first person rang it in. Some surprising definitions have been heard of.

The nature of Service

The absolutely key aspect is the nature of 'service. In almost all cases, service is defined in terms of transactions. For example, the UK government department performance indicators are in terms of how long it takes to reply to a letter, NOT how long it takes to solve a user problem. Service measures are almost always set by the supplier from their point of view, e.g. change management, fault management NOT in terms of user tasks or needs. So, getting a correct pension forecast might take ten letters and fifteen phone calls, but so long as each one was answered in a timely manner, the department has met its obligations. None of the answers has to be actually useful and nobody (in the department) measures the time to meet to solve the problem.

Setting SLA's at the level of transaction is almost always bound to be counter-productive. The needs of the user or the customer's business needs will be disregarded at best and probably undermined.

Process Contracting Limited© 2003