Service Level Agreement
Service Level AgreementService Level Agreements are set up between the Supplier and Customer to define the level of service. They can be used to set the Customer's expectation of delivery. Often they are used to measure the effectiveness of the workers of the Supplier organization. Sometimes there are penalties associated with failing to meet the Service Level or (less frequently) bonuses for exceeding them.
Often Service Level Agreements time based delivery deadlines - such as "Call back within 4 hours".
They can be used to measure reliability of hardware - such as "99.999% uptime".
I have a gut feel that Service Level Agreements should be useful but I finding it hard to find any that will benefit both the Customer and Supplier with the additional benefit of ensuring an efficient process.
Does anyone have any ideas?
What are you looking for? SLAs should, ideally, be negotiated for your circumstances, so you can't always take an off the shelf one. They define the requirements and expectations of both parties, and the consequences of under performance, and I'm having difficulty seeing why the ones you are finding aren't useful to you.
Ours (we're a managed infrastructure service provider), for instance, cover availability targets and help desk response time, define carefully what is meant by both, and define how poor service results in service credits for our clients. That helps make it clear what the client is getting, gives us something to aim at when we design infrastructure (people, process and technology), and provides a financial incentive for us to get it right. It doesn't *ensure* a efficient process, nothing does. It does provide clarity on what the process needs to achieve.
The problem I have is that we are an internal IT organization providing Application Development and Support to the business.
I can see how "uptime" can be measured, but I have a problem with help desk response time.
Often these say "Will call back in x hours". Then you get a call acknowledging the problem. This does not mean its resolved. The Customer is no better off.
If the SLA states "will be resolved in x hours" this may be an impossible target and the Supplier will be penalized for something that may be out of their control.
Resolving a certain percentage of calls within X hours, or averaging better than Y hours might work
So you add caveats to the SLA to cover these circumstances and very soon you get either an SLA with so many "get out clauses" that its useless or something that is so complicated its unworkable.
In my experience, most of these types of problems are covered by the development of something called an escalation procedure. The procedure describes the situation under which it is invoked as well as to whom the problem is escalated. Usually one escalates up the chain of command. --JimEatmon?
Additionally how do organizations who use SLAs against an internal providers handle the failure to deliver?
That isn't really a question about SLAs, but about performance measurement more generally. The sanctions depend on your organization, just like any other under performance. If you're an internal profit center, you can get paid less. If you're a cost center, then maybe performance related bonuses or appraisal ratings will be affected.
New Voice: Actually, I think this is addressing a valid concern about SLAs, that is, the belief that a piece of paper will establish a working relationship. One can write and rewrite an SLA forever without having the slightest affect on the level of service actually provided. If one is receiving poor service, find another service provider. If the service provider is another company, look for a replacement and negotiate out of the current contract. If the service provider is in house, look at providing the service within the department. Except in cases of extreme malfeasance, the SLA will not even serve as a valid basis to terminate a contract; they simply do not provide value.
I think that's a bit harsh. Consider the alternatives: if you don't have an SLA, how are you going to discuss what service and service quality you're expecting? Not having an SLA leads (in my experience) to the provider having one view of what they're providing and the client having another view of what they think they're going to get. This gap is a primary cause of dissatisfaction. This "gaps" model of service quality comes from Zeithaml (a quick Google gives http://qualitypress.asq.org/chapters/H1085.pdf for a discussion) - if you don't have some definition of what you're aiming at/expecting, you can't really manage the gaps.
It seems that my experience is the opposite in that: having an SLA leads to the provider having one view and the client having another, and the SLA inhibits discussion of the real service levels being provided. Creating a predictive document covering all situations in non-ambiguous detail is impossible, so an SLA must rely on a few general descriptive areas. For the provider, it is no longer important to maintain service levels, only to maintain the numbers in the SLA, and then manner in which the numbers are met is determined by the provider. Discussion is precluded as the provider simply pulls out the SLA numbers to prove that the customer is receiving good service, i.e., the customer complaints are not "based on the facts!" There is a big difference between providing service and maintaining an SLA.
Ah, that's a bad SLA then :) Getting to a good one takes considerable work. In your case, it seems likely (as is all too common) that you had a provider-view SLA (my guess is around things like network availability and initial response times) and not one around client issues (availability of the application to the end user with at most X response time). If you've got it is no longer important to maintain service levels, only to maintain the numbers in the SLA then you don't have a SLA - or at least, it's not an Agreement about Service Levels that you, as the client, see them.
At this point we may just have to AgreeToDisagree. We have one view that, given enough time and effort, a good SLA can be written and it will provide good quality service. There is an opposing view that the SLA is merely a symptom of the problem of isolation of the service provider from the service receiver and the SLA provides a surrogate for actual service. The latter view is expressed in the writings of WilliamEdwardsDeming and Alfie Kohn.
Run, do not walk, to ITIL, and buy the books. It's the source for best practices in IT service management http://www.ogc.gov.uk/index.asp?id=2261, and increasingly adopted worldwide. Consider joining the itSMF, the IT Service Management Forum. There is also open community to discuss all aspect of ITIL at the following URL: http://www.itilcommunity.com, and a more generic one, embracing the related standard (BS15000) at http://www.15000.net
Hardware Based Service Level Agreements
Software Development Based Service Level Agreements
Maybe SoftwareManagementManifesto can be translated into a software development service level agreement.
Software Support Based Service Level Agreements
Respond to requests and problems within 24 Hours and agree action plans with the User.
Update All problem logs on a weekly basis.
Confirm User accepts all is okay on closure of request / problem.
There's an introduction to the core elements of most SLA's here: http://www.sla-zone.co.uk. However, this doesn't cover the 'why' element of the question. Why, in my humble opinion, is an SLA necessary? Well I could say, why not? Surely SOMETHING is required to form the basis of understanding between the provider and recipient? That something should be readily understandable by both parties and agreed in advance. This is basically the key role of the SLA. It defines the acceptable boundaries between the parties. It is surely essential in modern business.
Resources
Executive guide on SLA at http://guide.darwinmag.com/technology/outsourcing/sla/index.html
EditText of this page
(last edited September 3, 2010)
or FindPage with title or text search