The Problem with SLAs, and How to Fix It

Too often, IT orgs mislabel other metrics and offerings as SLAs. Here is why that can muddy the waters.

Let me ask you a few questions:

• Does your organization have Service Level Agreements (SLAs) between the IT organization and non-IT senior managers within the company?
• Have your SLAs resulted in a significant, positive impact on the organization?
• Have your SLAs improved the perception and reputation of your IT organization?
• Do your senior business managers have clarity regarding how investments in technology have delivered business results? Do those managers recognize real business value from those investments?
• Would you characterize the relationships between IT and those senior managers as being healthy, business-like, and mutually beneficial?

Many IT organizations would answer the first question with a “yes”, but, there are no SLAs that have been documented, agreed, or signed between the IT organization and non-IT senior managers. But let’s say that you do have documented and signed SLAs - how did you answer the remaining questions?

If you could not answer any questions with “yes”, then I would ask – do you really have SLAs?

The purpose of an SLA is to establish a shared mutual understanding of how an organization realizes business outcomes and business value from its investments in and use of technology. According to ITIL®4, a Service Level Agreement is “a documented agreement between a service provider and a customer that identifies both services required and the expected level of service”.

This definition provides us with several things that we need to first understand if we are to be effective in our definition and use of an SLA.

First, an SLA is about a service – “a means of enabling value co-creation by facilitating outcomes that customers want to achieve”.2 This tells us a couple of things that an SLA should discuss – what is it that the customer values and what outcomes – or results – the customer wants to achieve.

Secondly, an SLA is about the customer – “a person who defines the requirements for a service and takes responsibility for the outcomes of service consumption”.3 This tells us that to be successful with an SLA, we need to identify who is the customer (not end-user) for the service discussed in the SLA. We also need to understand what that customer expects from consumption of service – both in terms of outcomes and in terms of business value.

MANY “SLAS” AREN’T SERVICE LEVEL AGREEMENTS

Which brings us to the problem with SLAs. In my experience, many SLAs aren’t even documented; fewer still discuss services. Rather, what many IT organizations refer to as “SLAs” are configuration settings within their ITSM tool. Further compounding the situation, those configuration settings typically have nothing at all to do with services, but rather with the operational activities of the IT organization. In other words, the “SLA” is not about the organization; it’s about IT.

But that’s not the only issue. Many IT organizations produce reports regarding performance against this so-called “SLA”, including metrics such as ASA, MTTR, FCR, response times, and other operational measures. These measurements have little to no meaning to colleagues who work outside of IT.

Make no mistake. It’s good to set operational performance targets within the IT organization for resolving an incident or fulfilling a service request. But how can business performance targets be established without first understanding what the customer needs from a service, how the customer perceives the value from the consumption of a service, and what business outcomes are enabled from the use of a service?

So, we need to define our services first, right?

Ideally, yes. Defining services in terms of business value and business outcomes should be defined before developing SLAs.

But many organizations hesitate to - or completely ignore – defining and documenting services. Some IT organizations aren’t comfortable with defining services because they don’t know the business of the business. IT leaders often rise to their level because of their technical expertise, and not necessarily their business expertise. Rather than engage other business leaders, these leaders look at defining services as a technology issue, and do a “service mapping”. A service mapping is just a network discovery starting from some supposed end user-facing starting point to some endpoint.

Sorry, that’s not a service – that’s a network map.

Some IT organizations list all the applications developed and implemented by IT, and call that list their “services”. This might be okay at first until an application is retired or replaced. Then what? Did the business need go away? Likely not. Applications are typically a component of a service, but not a service.

Some IT organizations use what many tool vendors call a “service catalog”, which is just a service request catalog containing listings of service actions and requests for goods and access that end-users may request from IT. Important to do? Yes, but again, not a service – those are service requests.

I can understand this hesitancy or avoidance of defining services. In my experience, identifying and defining services and establishing a (true) service catalog is a lot of work and rarely has any kind of immediate financial return on investment in year 1. But what defining services does is establish a shared understanding of what an organization values and the expected outcomes from the use of technology – topics that should be discussed within SLAs.

FIXING YOUR BROKEN SLA

Are your SLAs “broken”? If your current SLAs haven’t resulted in significant, positive impacts on the organization, improved the reputation of the IT team, brought clarity into the business value and results from investments in technology, and helped form strong working relationships between IT and senior business managers, then stop. You really don’t have SLAs. At the very least, stop calling those internal IT activities and measures “SLAs”, because they’re not. Those internal IT activities and measures are measures of IT performance, which have little meaning to anyone in your organization that does not work within IT.

Do you really need SLAs? Who within your organization is asking for SLAs? If your IT organization (including senior IT management) will not commit to documenting, agreeing, measuring, reporting, and regularly reviewing SLAs with senior business management, then don’t waste time developing SLAs. SLAs that do not result in a positive impact on the organization and on business relationships are a waste of time.

If you’ve made it this far, but haven’t defined a true service catalog, here are some things you can do to fix your broken SLAs:

Put your current measures where they belong. Measures like average speed to answer (ASA) and handle time (HT) belong to the service desk. Measures like mean time to resolve (MTTR) belong to incident management. These measures do not belong in an SLA. They do belong to IT. These measures indicate the internal performance of the IT team, not how a service is meeting business expectations for value and results.

Find the measures that your business cares about. An organization’s mission, vision, and goals (MVG) statements are a great source for learning about what is important to the business, even if you haven’t identified services in terms of business value and outcomes. Identify ways that IT contributes to or enables the organization to meet its MVG, measure those contributions, and include those measures within SLAs.

Find the measures that your business cares about. Many organizations conduct a business impact analysis (BIA) on a regular basis. A BIA identifies an organization’s vital business functions (VBF) and quantifies the impact of service loss. A VBF is a function without which an organization will not exist. For example, a bank’s VBFs include accepting deposits and granting loans. How does IT enable the bank to successfully perform these VBFs?

Read the organization’s latest BIA. Identify the measures that indicate the business results of performing those VBFs, and how IT contributes to those results, and include those measures within SLAs.

Ultimately, looking at the measures that the business cares about will drive IT to define its services in terms of business value and business results. In the meantime, these measures will start to reorient how your IT organization should be thinking about SLAs.