“Service Level Agreements are the cornerstone upon which effective IT Service Management is based, and they are central to building and maintaining a positive relationship between the user community and the IT Department”
It is not possible to understate the benefits of good Service Level Agreements however, we rarely see good Service Level Agreements in practice.
Almost without exception they tend to be documents written by someone in the IT Department, from an IT perspective; and they generally relate to what IT thinks it should (or should not) do.
As a result, most Service Level Agreements are largely unused and unloved. They sit on a shelf gathering dust, only seeing the light of day when somebody in IT needs to check the definition of Availability just to make sure that the last e-mail outage does not count as a period of unexpected unavailability.
Because of this, it would be fair to state that the great majority of Service Level Agreements are at best rarely referred to – and at worst they can actually lead to a deterioration in the relationship between the user community and IT.
This guide provides you with 5 simple and practical tips to help make sure that your Service Level Agreements are worthwhile and add value to your business.
These tips are not intended to provide an exhaustive and definitive list of all the things you need to consider when putting in place Service Level Agreements.
Instead they are intended to provide you with some key nuggets of practical advice that are not found in any of the standard ITIL books. They come from our experience of helping multiple organisations to set up and maintain truly effective Service Level Agreements.
There is no getting away from the fact that some of these tips contradict the advice provided by ITIL. This is not meant as (and should not be taken as) a criticism of ITIL. Rather it is simply an honest reflection of where we have found that the advice given by ITIL does not work effectively in a real world situation.
Tip 1 – Keep each Service Level Agreement “Short and Sharp”
How short? Two sides of A4 is ideal, and the core contents of the SLA should be limited to a maximum two sides of A4.
To keep to this length we recommend that you remove all of the ‘padding’ and all of the sections that really add nothing to the SLA.
It is tempting to include sections on things like as batch turnaround times, service continuity arrangements, change management procedures, service hours, details of how to contact the Service Desk, security, printing, etc. However, none of these are actually needed in an SLA.
Only include the sections that are needed, that are going to be of some value and that actually add something the SLA itself. The suggested list of contents for a typical SLA would be:
- Introduction – containing brief description of the Service, who the customer(s) is
- Duration of agreement – start and end date of the SLA (maximum duration should be no more than 12 months – see Tip 4)
- Service quality criteria & targets – how will service quality be measured and what level of service does IT commit to provide
- Service performance reports and reviews – when will the service reports be produced (and what will they contain) and when will service reviews be held
- Signatures – customer and IT representatives signing the SLA
There should be no need for appendices – and most definitely no Glossary of Terms. If you write an SLA that requires a Glossary of Terms you have written a bad SLA. Start again and remove all ambiguous and technical terms, and replace all acronyms.
Write as simply and as clearly as possible. Do not use pseudo legal or technical terms. It is also essential that the service quality criteria and any service performance targets are easy to understand and are written from the user and not the IT perspective.
Tip 2 – Drop the caveats (stop making excuses!)
Most Service Level Agreements are full of caveats.
Do any of these seem familiar? These are all examples taken from real life Service Level Agreements that we have come across.
- The Availability targets for all Tier 1 Applications will not apply in the case of a serious network issue
- The resolution time for Incidents will not apply if the underlying cause of that Incident is found to be a ‘bug’
- These Service targets will only apply during normal working conditions(‘normal working conditions’ were not defined in the SLA)
- e-mail will be deemed to be available should the e-Mail server not be unavailable. Please note: it may not be technically possible to send or receive emails when the e-Mail service is available
- The Service performance targets as stated in this SLA will not apply in exceptional conditions. Exceptional conditions are those which IT deems to be outside acceptable limits of technical stability (anyone actually know this means?
Remove all caveats. They undermine the purpose, integrity and value of any SLA.
We are not suggesting that there will never be exceptional conditions, there clearly are – however there is no need to list these in the SLA.
Including caveats in the SLA can be viewed with a lack of “trust”. It can appear that IT are avoiding being held responsible for meeting its commitments. The caveats tend to focus attention on what IT cannot or will not deliver and can accentuate the negative. This tends to undermine the whole point of having an SLA (which is essentially to demonstrate the positive commitments).
Caveats are not required and may do more harm than good. There may be some occasions where IT fail to meet the stated service performance targets due to circumstances outside the direct control of IT. This happens, and can/should be explained in the SLA review process.
Tip 3 – Do not use Availability to measure service quality
It is an unfortunate truth that most SLAs are still written from the IT perspective.
This is about more than simply the language that is used (although technical terminology and abbreviations are still very common). It is also about the fact that almost without exception the service quality criteria and service performance targets found in SLAs are all defined from the IT perspective.
Availability is the perfect example of this. By for the most common service quality criteria found in an SLA is ‘Availability’. And the most common service performance target would be ‘all the nines’ e.g. 99.xx%.
However, not everyone understands Availability and what it really means. For the most part Availability is defined in the SLA and somebody in IT can tell you how many minutes unplanned downtime is acceptable with an Availability level of 99.89%. However, to the typical IT user Availability means nothing. It is therefore a completely meaningless measure of service quality.
Availability based service targets are actually a source of potential conflict between IT and the users. This arises due to the way Availability is measured and rarely reflects the user experience (and expectation) of what Availability actually is.
IT provide figures to prove that the Availability targets are being met however, the user perception can be very different. The users may not be able to put any form of figure on downtime, but their perception could be that the service has been unavailable when they wanted to use it.
From an IT perspective the Availability targets are being met. However, the user’s perspective of the service quality is poor.
In this instance, instead of helping to build and develop a positive relationship between the user community and the IT Department; the Service Level Agreements can become a source of conflict and mistrust between IT and the users.
How can this be avoided?
Firstly, we suggest that you don’t include Availability as a service quality criterion in your Service Level Agreement. Instead use criteria that is reflective of the actual service quality from the user perspective.
Secondly, restrict the service quality criteria and associated performance targets included in the SLA to a few key and meaningful points. Do not attempt to measure everything as this can cause confusion for the user. Instead concentrate on what is really important – for example measuring a few key areas that are truly reflect service quality from the user perspective
Instead of Availability, why not consider using Reliability (MTBF) and Service Recovery (Maintainability – MTTR) as your key service quality criteria and have service performance targets for both?
Reliability would be defined as the maximum number of unplanned service outages within a given time period, and Service Recovery would state the maximum time any single unplanned service outage would last.
For this to be effective would need to get agreement with the users on the definition of an unplanned service outage. You should also be able to measure the number and duration of unplanned service outages as experienced by users.
Tip 4 – Keep them up to date
Service Level Agreements are not cast in stone. It is essential that they are kept up to date and relevant. You must be prepared to update them at any time to reflect changing service quality requirements or IT capabilities.
To make sure this happens you need to ensure that every SLA has an expiry date. I would suggest that SLAs should have a maximum life span of 12 months. This forces you to review and update each SLA on a regular basis, and this in turn ensures that you avoid the very common problem of having lots of completely irrelevant and out of date SLAs in place.
Many IT organisations seem reluctant to update an SLA that is in place due to the work involved with the review. This approach may reduce the overhead of maintaining the SLA’s on a regular basis, however it also means that the SLAs in place are increasingly irrelevant or obsolete. The regular SLA review allows both the user and the IT Department to reflect on the Service provision and provide feedback on improvements.
Unless reviewed at regular intervals, the service quality criteria and service performance targets in the SLA will become increasingly meaningless. The fact that the IT Department is meeting the targets will become irrelevant. This again may lead to deterioration in the relationship between the IT Department and the user community.
