Understanding Service Level Agreement (SLA)

I was in a discussion yesterday with one of my co-workers who is new into IT service management. We were talking about agreements, and I gave a short lecture on Service Level Agreement (SLA). Oh well! It tickled my brains, so why not extend it to writing, and here it is.

A SLA in simple words is an understanding or an agreement between the person getting the job done and the person working. The agreement could stretch from as simple as agreed deliverables to a complex one that lists out each and every parameter, in detail. The content is highly subjective and is discerned between the two parties. SLA is generally initiated and owned by the client, and is generally an agreement between the client and a service provider.

If I am an organization providing IT services to a telecom company, my SLA would list out the different issues that might arise, and tag each issue with an agreeable priority. Based on the priorities, we would agree on a resolution timeline. Further, we may extend the concept to cover how soon we acknowledge to the issue on hand.

As per ITIL, issues are referred to as incidents, and the agreement on resolution timelines is resolution SLA and acknowledgement agreement as response SLA. As I said earlier, the list of things you can put in a SLA can go for pages together. An ex-colleague of mine who used to work on drafting SLAs used to joke that he has started writing novels, as the SLAs he used to spin were close to 150 pages.

Before I end, there are two other types of agreements that are in vogue along with the SLA. An Operation Level Agreement (OLA) is an understanding between internal teams of the same organization. It is similar in nature to a SLA except for the parties involved. An under-pinning contract is an another agreement between the service provider and the client. This agreement will concentrate on the business side of things, like the economics and the number of people involved to realize the contract.