by Ian Logan, http://www.casaubon-eck.co.uk/
© 2002 Ian Logan. All rights reserved. 

This article is based upon my experiences in introducing Service Level Agreements (SLAs) into a large, widely dispersed organisation, which was going through the outsourcing process. It is cited as a successful implementation in the definitive ITIL textbook on Service Delivery: ITIL Best Practice for Service Delivery (published by The Stationery Office, 2001). 
What do I mean by SLA Culture? 
An SLA Culture is one: 

Which is customer and user focussed 
Where the idea of providing a service is paramount 
Which seeks constant service improvement 
Where staff and management have bought into the spirit of the SLA 

The SLA Project set out to introduce a 'single' SLA with the in-house IT service provider and to establish a single set of contractual arrangements covering the relationship between the organisation and its IT Services department prior to the outsourcing of the IT functions. However, it was recognised all along that the benefits of the SLA could be delivered with or without outsourcing (i.e. SLAs can benefit any organisation that seeks value for money and wants to deliver a good service). 
In order to develop the Single SLA we entered into discussions with: 
Senior managers 
Panels of customers 
Specialist groups 

We spoke to senior managers throughout the organisation to make them aware of the Project, to address any particular needs or concerns they had and to gain their commitment. We asked the direct question: “Will you support us in what we are doing?” Without failure (if not without hesitation) they all answered, “Yes”. 
The customer panels played the central role since they were made up of people who were able to offer an overview of how the IT services and systems were perceived by customers and users, how they supported the delivery of the business and what the priorities of the customers and users were. The customer panels had a key role in steering our negotiations with the IT service provider, and in establishing the standard SLA requirements 
The specialist groups consisted of people who had particular in depth experience and knowledge of individual IT systems and were there to ensure that the relevant factors concerning individual IT systems were taken into account. 
Alongside these discussions we held negotiating sessions with the IT service provider, in which we reported back on the outcome of the discussions with the customer panels. As a result of the steer given by our customers, we agreed with the provider significant changes in service levels, e.g. higher availability targets and a set of incident priority levels designed to support the users’ ability to deliver the business at the required place and time and by letting the user assist in determining the priority assigned to their incident. 
By the end of the Project we had established the following set of inter-related products: 

1. The Single SLA, made up of three elements: 
The Framework SLA – dealing with the organisations formal requirements of the IT service provider and apportioning roles and responsibilities at a high level 
The Standard SLA – documenting the support and delivery requirements of the IT services and systems 
The Specific SLAs – detailing the relevant cost-justifiable exceptions to the Standard SLA for individual services and systems. These were further divided into three categories: minor variations from the standard; unique or discrete systems or services requiring their own agreements; and project related or temporary 

2. The Required Services Description (RSD), detailing the service lines that the IT service provider was expected to maintain. 
3. The Commissioned Programme of Work (CPOW), which recorded details of all work commissioned from the IT service provider at any given time. All work was commissioned from the provider through the contract manager, except in the case of formally approved projects, which obtained their resource directly, subject to a specific agreement (see above), or where frequent use of the provider for relatively small jobs did not merit this overhead. 
4. Call-off arrangements were implemented for frequent ad hoc tasks, so that the customer could deal directly with the IT service provider within agreed costs/resource tolerances. 
5. The Service Catalogue, which provided the customer with an easy to understand reference guide to the IT services, and informing them of the levels of service to which they were entitled. 
Not on the above diagram, but underpinning the relationships between all the products was a set of jointly constructed management procedures, covering such diverse issues as escalation, communications, work requests, reporting and reviewing, third party supplier management, etc. 
The model I developed in this Project, like all models, provides one way of going about the task in hand. It is not intended that it should be applied to every organisation in every situation. However, it does show what can be achieved, if you get the business on side at the start and win the hearts and minds of managers and staff at the outset, and if you listen to the customers. Because, of course, the secret to giving the customers what they want is to ask them and to listen to the answer.