Do you really need a SLA?

Share twitterlinkedinmail

Think of the last time you had a poor service experience. Maybe it was at a restaurant when your dinner order didn’t come out quite right. Perhaps it was at a car wash after you noticed that the interior of the car really didn’t get cleaned as promised. What did you do?

Likely, you did one or more of the following actions:

  • Expressed your dissatisfaction to whomever was serving you
  • Asked to speak to a manager
  • Left (with or without paying)
  • Told your friends about your poor service experience
  • Haven’t done any further business with that person or establishment

What you probably didn’t do was get out your copy of a SLA (Service Level Agreement), point at it, and say “this is how you should be delivering this service”!

Why do some in IT think that simply having a SLA will solve all  service issues with customers? Why don’t we just deliver good service? Why don’t we just clearly and regularly communicate with (not “at”) our customers? Do we really need SLAs?

Perhaps it’s as simple as reading the tea leaves.

When our IT customers are not getting the service they need, here’s what happens:

  • Shadow IT – Customers develop their own solutions and avoid interacting with IT.
  • IT gets excluded – IT is not viewed as a “solution partner”, and therefore doesn’t get a seat at the business strategy and planning table.
  • Outsourcing – The business-IT partnership is unique in that one partner (the business) can “fire” the other (IT). Although there are often good business reasons for outsourcing elements of IT, is the primary reason because of poor service quality?

What is the point of a SLA? Fundamentally, a SLA is simply a vehicle to encourage relevant, meaningful discussions regarding the quality and value of services provided by IT and the business it serves. I would argue that the SLA itself is nothing more than a sheet of paper; it’s what an organization does and how it acts as a result of that sheet of paper that makes having a SLA valuable. In too many situations, however, IT organizations develop SLAs that are pointless sheets of paper.

SLAs are pointless when they:

  • Sit on the shelf, collect dust, and are never reviewed – The primary reason for having SLAs are to set and agree expectations, then regularly review and discuss how services are being delivered compared to those agreed expectations. These SLA reviews are critical for confirming value and identifying areas for improvement. If the SLA is just “sitting on the shelf”, developing it was a waste of time and resources.
  • Aren’t signed by customers – If a SLA is not signed by both IT and the customer (yes, I’ve seen this!), this means there really isn’t an agreement!
  • Reference measures that are meaningless to business – While measures like server uptime and network utilization are important for the operations of IT, these measures have no meaning to the business. The SLA should address the question “what’s in it for the business”, supported by measures and reports that answer that question.
  • Lack ownership – If there is no accountability for managing the SLA, or ensuring that the terms of the SLA are met, then having a SLA is pointless.
  • Are not lived by management – Good service starts with at the management level of the organization. If management takes an approach of “management by exception” and ignores the terms of a SLA, the SLA is moot—it really doesn’t matter what has been written.

If you think about it, developing and maintaining SLAs is a lot of IT overhead; one could even argue that it is non-valued added work.   Developing and publishing reports, conducting service reviews, and maintaining the SLA takes time and costs money. Perhaps IT should ask if the business would like SLAs, and explain what it is and how it works. If customers willing to pay for IT to develop and maintain SLAs, then IT must work with the business to develop and maintain SLAs—keep in mind that this is also overhead from the business perspective as well!

So are having SLAs “bad”? No, SLAs aren’t “bad” — when defined, enabled, and used appropriately.

  • Properly defined SLAs will describe “what is success” for both the provider and the customer. SLAs will clearly establish shared expectations for services. Most importantly, the SLAs will capture and document what the customer values, and how IT is going to enable or deliver that value.
  • To enable the SLA requires that services (not just products) are defined and documented, with each service having a named service owner who is accountable for delivering on that value as defined in the SLA.   SLAs also must be enabled as part of a larger, integrated ITSM program. Effective ITSM processes must in place to ensure that an IT organization can deliver services consistently, measurably, efficiently, and effectively.
  • The appropriate use of the SLA is as a basis for frequent, regular, relevant, and meaningful discussions between IT and the business it serves. The SLA should not be thought of as an “enforcement mechanism”, but rather as the means by which to objectively discuss successes, value outcomes, and improvement opportunities. The SLA is a great way for IT to demonstrate its commitment to excellence and business success, and for the business to explore how it can exploit its use of IT as a strategic asset and competitive advantage. Used appropriately, an IT organization and the business it serves develop a productive, mutually-beneficial partnership.

Need help defining SLAs that are meaningful? I can help with that –  contact Tedder Consulting today!  For more pragmatic insight into the world of service management, click here to subscribe to my newsletter!

Share twitterlinkedinmail

Leave a Reply

Your email address will not be published. Required fields are marked *