Branimir Valentic Once your IT service is in the live environment – that’s when your service’s “adult life” begins; i.e., it’s time to see how good (or bad) the service is. Users will start using it and judgements will be made. Firstly, users will judge functionality (according to ITIL – utility or fit for purpose). That will be the justification as to whether all customer requirements are fulfilled. Secondly, users and customers will judge how well you maintain agreed characteristics of the service (or warranty – fit for use, i.e., availability, capacity, security, and continuity). There is no discussion; both utility and warranty are set much earlier.
You can hardly have any influence on utility (fit for purpose; i.e., what does the service do). Warranty (characteristics of the service) is your point of interest once the service is in the live environment. Namely, all the characteristics of the service that you agreed on with your customer have to remain as agreed (e.g., capacity means usually some performance characteristics of the service like throughput or number of transactions in, e.g., a minute, etc.). The Service Level Agreement (SLA) is the document that will clarify your relationship with the customer, but also your obligations (OK, and the customer’s as well) to maintain the service’s quality level.
Why bother?
Actually, why would you bother to have a clear, concise, and descriptive SLA? Isn’t it easier to sit down with the customer, agree on what needs to be done, and start working? Well, easier said than done. Once there is a different view on the same issue – you’ll realize that there must be something better than a verbal agreement. If it isn’t you – your customer will require that.
See it from the positive side – once you have a written agreement, you know your obligations. So, resource planning can be made as well as budgets allocated. If I was responsible for delivery of services, then I’d be very happy if I knew exactly what and how something had to be delivered. Further on, in such case I could instigate control and measurement mechanisms, reporting, collaboration with customers, improvements… etc.
Requirements and recommendations
Since ITIL is, generally, not prescriptive, there are no strict requirements regarding the SLA and its content. Actually, by reading ITIL literature you will find a lot of useful tips, but no fixed requirements as in ISO 20000.
ISO 20000 is a set of requirements related to the (IT) Service Management System (SMS) and, as such, it sets requirements towards the Service Level Management process and the SLA. Direct requirements are “simple”:
- Existence – there should be one or more SLA for every delivered service.
- Requirements – service requirements (agreed with the customer) have to be considered while creating an SLA. That includes (agreed) service targets, workload characteristics, and exceptions.
- Change management – changes to the SLAs should be controlled by the change management process.
Indirect requirements are related to the service catalogue (changes in the service catalogue must be reflected in SLAs) and performance monitoring (against service targets).
What to include?
Generally, it’s hard (or better to say – impossible) to provide a cookbook for the SLA content. The reason is that every service is different, and every customer sets their own requirements. But, from an experience point of view, there are some elements that are either common to most of the SLAs or are recommendable to include in the SLA (regardless of whether you are implementing ITIL or ISO 20000):
- Header and footer of the document – the SLA is an agreement, i.e., a legally binding document between the supplier and the customer. So, it has to contain the legal part of the document.
- Service description – what do you support; i.e., describe the functionality as briefly and precisely as possible.
- Scope – define what is included in the SLA, but also what is excluded (e.g., training or delivery of licenses and/or equipment).
- Performance supported – this could include supported service hours (e.g., 24×7), or some detailed descriptive parameter (availability, capacity), like number of transactions per minute.
- Processes – I found quite often that the service provider and the customer have different expectations from, e.g., the incident management process. Once an incident is opened, the SLA clock starts ticking. When the incident is resolved, the IT service provider stops the clock. The catch is that the customer expects the root cause to be eliminated, which is the job of problem management. Besides that root cause analysis requires high expertise, it also requires more time; therefore, it’s advisable to make a distinction between these two processes. It’s the same with change management – who is doing what, how the communication works, what are the change categories… etc. Therefore, if possible – include process definition in the SLA.
- Contacts – define contacts on your (as well as the customer’s) side and describe how customers and users can contact you (e.g., web portal, mail address). Include a description of responsibilities on both sides.
- Security – that applies to the confidentiality, integrity, and availability of configuration items that are part of the service, but also to the relationship between you and the customer (usually meaning – NDA or Non-Disclosure Agreement).
- Charging – you certainly shouldn’t forget about this element.
- Reporting – which reports, what is the frequency of sending reports, who sends them to whom… etc.?
To have one, or not to have one?
Having no SLA is the worst option. If you already have one, check whether the SLA helps you define your relationship with the customer and whether all responsibilities are clear. Namely, SLA means obligation – permanent and clearly defined. I’m sure that proactive and efficient IT service suppliers don’t mind signing the SLA. On the other side, service suppliers who hesitate to sign an SLA should think twice. The SLA helps the customer to get what he pays for, but the same is valid for the supplier – the SLA enables them to charge for the service they provided.
Use this free Service Level Agreement (SLA) template preview to get familiar with the content of a SLA.
