I had a conversation about SLAs again this week. Suffice it to say that I came away with the feeling that there is so much misunderstanding about the purpose and rationale of a SLA.
What is an SLA?
An SLA, or Service Level Agreement, is an agreement regarding the quality of service delivery between a customer and a service provider. The primary goal of a SLA is to establish mutually-agreed targets and responsibilities of the service provider and the customer.
Some IT people get so hung up what a SLA says (or doesn’t say) that they lose sight of the core issue – providing good service to the business. In their minds, the SLA seems to take on some magically quality, as in the very existence of the document will make all service issues, poor planning and bad communication simply disappear.
It doesn’t. Strictly speaking, it’s just a document with some words on it. Well, it’s supposed to be a written document anyway. Frequently I find organizations who say that they have “SLAs”, but are unable to produce any such documents.
I would argue that unless there is a significant business requirement for defining and documenting an SLA, don’t write one. SLAs should not be defined without a lot of thought and discussion between the business and IT. If the IT organization is providing a good service, delivering recognizable and demonstrable value, underpinned by good customer service skills, do you really need an SLA?
My point is that I’ve seen too many IT organizations in their quest to develop SLAs, exasperate what is usually an untenable situation and commit what I would call the “Seven Deadly Sins of Service Level Management”.
- Over delivery – Over delivery means that the IT organization is exceeding the performance targets identified in the SLA. Why is this a bad thing? A SLA is meant to define and mutually agree what is needed and how it will be measured. This agreement forms the basis for what the business is willing to pay for the services IT provides. Over delivery means that IT is doing more than what the organization required. Over delivery comes at a cost, with one of the most significant being reputation damage to the IT organization. When the IT organization over-delivers then “scales back” to agreed performance levels, it can leave the customer with the perception that IT was “sandbagging” during SLA discussions or is really not focused on business value.
- Making a promise that a vendor support contract can’t keep – In other words, promising something in the SLA that a contract with a third-party supplier will not deliver. If the support agreement with the vendor says “next day support”, the IT organization cannot promise “two-hour response time” in a SLA.
- Writing SLAs in “IT-speak”, not “business-speak”– The customer does not specifically care about applications or unpinning technologies. The customer does care about the value received and the outcomes that result from the use of IT services. Writing a SLA using technical terms and jargon is meaningless to business.
- Measuring and reporting on the wrong things – Likewise, the customer does not care about server uptime reports, capacity utilization reports, response times, or network utilization. The customer does care about number of orders processed, widgets shipped, customer calls processed, and value realized. SLA reports should reflect business measures not IT measures.
- Customer? What customer? – I’ve seen several instances of IT organizations utilizing (and reporting against) the “SLAs” that are pre-configured within their ITSM tool. Make no mistake – the IT organization must have defined performance targets. The issue I have with using the “SLA” as it is pre-configured within the ITSM tool is that the customer was usually not consulted, much less identified, regarding the validity and relevance of those targets. In other words, there is no “agreement”. Secondly, the targets usually have little meaning to the business, because the targets relate to a product or activity and not a service. Which brings me to my next ‘deadly sin’…
- Having SLAs around “products” and “activities” – Repeat after me: “products” and “activities” are not “services”. SLAs are Service Level Agreements. Yet many SLAs (and ITSM tools for that matter) would have you believe that products like smartphones or laptop computers or activities like resetting a password are “services”. Products and activities are geared toward the consumer (user) and provide the means by which services are used; in and of themselves, they are not services. If IT only talks about the products it provides and activities it performs, it only commoditizes what it does.
- Never conducting Service Level Reviews – What is the point of developing SLAs and all of the underpinning measures and reports if the IT organization doesn’t conduct regular, periodic service reviews with its customers? SLAs should not sit on a shelf collecting dust! The service level review is a great opportunity to confirm the value of IT services with the customer, as well as to demonstrate partnership and identify improvements. Yet many IT organizations do not conduct these reviews.
When designed, implemented, and used effectively, Service Level Management (SLM) can be one of the most powerful processes by which IT can demonstrate value to the business it serves. But done poorly, SLM only leads to mistrust and tension between IT and the business. If your IT organization has committed one (or more) of these ‘seven deadly sins’, what can be done?
Assuming the process is defined, here are my seven steps to SLM redemption.
- Start by first defining or ensuring that you’ve defined services in terms of business outcomes and business value, not products and things.
- Identify the customer for each service, and review the service definition with that customer.
- Confirm the value and outcomes provided by each service, and how the outcomes and value should be measured in business terms, and establish targets for those measures.
- Ensure support vendor contracts can support those targets.
- Confirm or develop service measures that reflect the agreed value and outcomes.
- Communicate and publicize those agreed services and expectations within IT.
- Define, agree, and obtain signature on SLAs and schedule the first service level review.
Has your organization committed some “deadly sins” when developing your SLAs? Contact Tedder Consulting today and get on the road to redemption! Or, for more pragmatic insight and opinions regarding service management, click here to subscribe to my newsletter!Share