SLA
Image: The Schools HR Co-operative

Leveraging SLAs

Service Level Agreements (SLAs) should be a standard feature of internal service provision – whether that is an IT, Finance or HR service. Of course, IT SLAs are the most common, although shared services centres providing other services are now more often making use of SLAs.

1. What is an SLA?

ITIL (Information Technology Infrastructure Library) defines an SLA as an “agreement between an IT service provider and a customer. A service level agreement describes the IT service, documents service level targets, and specifies the responsibilities of the IT service provider and the customer.” (ITIL Glossary).
That definition includes some key aspects of SLAs that are often forgotten, misunderstood, or misapplied:
  1. Agreement
  2. Service
  3. Targets
  4. Responsibilities.

2. Agreement – an SLA is both a carrot and a stick

We all know what an agreement is, but it’s worth – with regard to SLAs – refreshing our understanding. The Oxford Online Dictionary defines “agreement” in a number of ways: “harmony or accordance in opinion”; a “negotiated arrangement”, and; the “absence of incompatibility”. These to me suggest an almost engineering view of an SLA as a form of need-response specification. Too often, however, SLAs are seen more as contractual documents that can be used to punish, or excuse, poor service. Or the specification aspect is rushed, with more attention being given to contractual aspects in case something goes wrong.
For an SLA to be effective, it must provide for an exchange of value between the customer and the provider in the form of the classic “win-win”. That should be the starting point of both parties – “how can I ensure that this arrangement creates value for both parties?”

3. Services – SLAs are a need-response specification

Of course, the services to be provided must be described in the SLA. The three key components of the service description are:
  1. Purpose – benefit to the customer, the context/environment in which the service is to be provided, and the impact the service is to have on users and other stakeholders
  2. Need – the customer’s requirement (components of the service, who receives the service and when, priority, scale and so forth)
  3. Response – the provider’s specification of the response to the customer’s need (what the service includes/excludes, how the service will be provided and when and where, plus key attributes such as speed, reliability, maintainability and so forth).

4. Targets - SLAs are not targets

Often I’ve heard people say “we always meet our SLAs”, or something similar, referring to SLAs as targets and not agreements. Service level agreements have many components and service level targets are but one – albeit important - component. This is not a matter of semantics. If one sees an SLA as just targets, the broader value of negotiating an SLA will be lost.
It’s worth raising a few points about targets, however:
  1. Targets should be realistic – they should primarily accurately reflect the true level of service the customer requires (why demand, and pay for, 99.99% if 95% is sufficient?)
  2. Targets should be in context (for example: 95% availability during office hours …)
  3. Targets should include Action Limits (for example, if during any one day, unavailability exceeds 15 minutes, then …)
  4. Target granularity should be sufficient to address variation in customer need (for example, a user may have one major site and multiple minor sites; 95% availability across all sites would mask a significant outage at the major site)
  5. Targets should be very limited in number for each service (a large number of targets may smooth “blips” in any one).

5. Responsibilities – SLAs are about partnerships

As discussed above, SLAs have a lot to do with harmony and compatibility and so cannot be simply a list of matters that are the responsibility of the provider. Providers cannot be successful unless the customer works with them. Part of the negotiation must involve clarification of all the “I can do this, but that will require you to do that” items.

Other important aspects of good Service Level Agreements include:
  • Guarantees
  • Improvement

6. Guarantees - SLAs require meeting of commitments

A service guarantee states the level of service a customer can expect from the supplier, and how and to what extent the supplier will compensate the customer for service that does not meet that expectation.
There are some good reasons for including service guarantees, including that they:
  • Force the provider to focus on what is really important to its customers
  • Force the customer to consider what is really important
  • Set clear service standards
There are also some reasons for excluding service guarantees:
  • External variables that are beyond the provider’s control
  • Cheating (by either party)
  • High costs (to both parties).
Overall, service guarantees are beneficial for the attention they bring to the critical service aspects that should be included in an SLA and what level of performance is available and needed.

7. Improvement - it's what SLAs are about

Improvement is the often-missing piece of an SLA. Most will specify some reporting and, perhaps, review mechanism but these will be quite “static” in nature, focusing on performance against targets. But in a changing and challenging world, more is required. “Dynamism” must be added by formally looking for opportunities for improvement. These may be on the customer side – such as improved training for users so that the number of calls to the help desk is reduced (thus opening the possibility of a lower-cost help desk) – and the provider side – such as greater investment of effort in root cause analysis of incidents leading to fewer incidents being raised (and thus opening the possibility of fewer help desk staff solving incidents and more providing value-add services).

See the BusinesSPM Project "Boral SBS Service Level Management" for a real world example.