What should go into an SLA?
You mentioned in your blog that service-level agreements were on the rise and even gave some instances in which companies may have them and benefit from them, but what should go into a service-level agreement? Is it just "here's what you have to deliver and here's what happens when you don't"?

My organization is looking to outsource some of our systems, but we don't know the questions we should ask when drafting an SLA.

Good question. And this is a question that many organizations just like yours are facing. You're thinking about outsourcing a particular IT or business function, but are unsure about the best way to ensure that you will receive what you're actually paying for.

Let me answer your question in two parts. First I'll describe key components that should go into every SLA, and then I'll share a thought or two on "best practices" for developing SLAs. Let's start with the basics. To begin with, every SLA should contain at least the following:

  • Introduction -- The parties to the agreement, a brief description of agreement, signatories, dates, scope, the responsibilities of both parties and a description of the services covered
  • Service hours -- Standard business hours and off-peak hours, wrapped together into a service calendar
  • Service performance -- Define service performance requirements in terms of availability, reliability, throughput, transaction response time or whatever metrics that are most relevant to the outsourced service
  • Support -- Support hours, target time to respond, target time to resolve incidents (by priority level)
  • Penalties and credits -- When outsourcing, penalty clauses are a "must"; credits can be considered for rewarding service providers providing superior performance
  • Service reporting and reviewing -- Define content, frequency and distribution of service reports, and the frequency of service review meetings
A few best practices to keep in mind when developing your SLAs include:
  • Keep SLAs short -- The longer the SLA, the more complex it will be for you and your service provider to govern.
  • Focus on the outcomes -- Try not to "micromanage" the service provider by regulating CPU utilization, temperature in the data center or other small details, but rather focus on the "outcomes" that you are looking for, such as application availability and response time, number of completed transactions per hour, etc.
  • Maintain ability to audit performance data -- Make sure when negotiating with your service provider, that you have access to performance data to perform your own auditing or "outsourcing governance" using a service level management solution.
Often the biggest hurdle to jump when creating an SLA is simply getting started. Hopefully this information will get you started and heading in the right direction.

This was first published in March 2006