Branimir Valentic
June 14, 2016
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.
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.
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”:
Indirect requirements are related to the service catalogue (changes in the service catalogue must be reflected in SLAs) and performance monitoring (against service targets).
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):
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.