Do You Need to Elevate Your SLAs?

Does your IT organization have documented and signed Service Level Agreements (SLAs) with key managers and stakeholders in your company? If so, are your SLAs providing any value to your company? How do you know?

How do you know your SLAs are providing value to the company?

All About an SLA

An SLA is an internal agreement between a service provider (IT) and its customers. In this context, a customer is the person or group that defines the need for a service and pays for it. A good SLA provides mutual benefit to both the IT organization and the business it serves, as it describes the relationship of what IT does for business success via the use of technology.

The basic components of an SLA are:

• Description of the service. What is the service and how does the service deliver or enable business outcomes?
• How “value” will be measured. Value is really a perception. Understanding what the business finds valuable and how that value should be measured is critical.
• Mutually-agreed performance targets. What are the (select few) performance targets that the IT organization must achieve to result in customer satisfaction?
• The frequency, format, audience, and contents of performance reports. IT must report on how well it is performing in delivering the service described in the SLA—good or bad. If IT doesn’t keep (and report on) score, neither IT nor the customer can know how well the service is performing.
• The frequency and participants for Service Level Reviews (SLRs). Regular SLRs are critical for success with SLAs.

Considerations for Defining SLAs

Defining and leveraging SLAs can be a good thing for both the IT organization and the business it serves.  Good SLAs are conducive to powerful conversations and mutual understanding about the use of technology within a business as well as enable continual improvement. But many organizations blindly establish SLAs without thinking them through. Before rushing into defining an SLA, here are some questions to consider:

• Do you really need an SLA? SLAs, done well, require a level of effort from both business colleagues and the IT organization to glean the benefits. What is the business driver for developing SLAs?
• Who will “own” the SLA? To be effective, the SLA must be jointly-owned between the business and the IT organization, as neither can be successful with the use of an SLA without the other. To say it differently, no ownership means no one cares.
• Do you have the right people involved with defining the SLA? If the people that sign the SLA cannot have any influence over the use and perception of the service, then you don’t have the right people involved.

But that’s not all. Here are some other points to consider:

• SLAs are not SLAs unless they are documented and signed. I’ve encountered many organizations that claim to have SLAs, when all they have done is configured some settings in an ITSM tool. What those organizations have are SLGs—Service Level Guesses. There is nothing mutually-agreed, documented, and signed. It’s just IT’s guess about what to measure and report.
• SLAs that sit on shelves are worthless. In my experience, this is the result when someone checks “define SLAs” off of their to-do list.  There was no understanding or agreement for the use of the SLA; it was just something that needed to get done. 
• SLAs are not weapons for hitting consumers over the head. I’ve seen a number of IT organizations tell consumers “that’s not in the SLA” or “we met our SLA.” This is frequently indicative of an SLA that does not accurately reflect the business need. It certainly doesn’t reflect a service-oriented attitude.
• SLAs cannot be “one and done.” Business needs and IT capabilities are ever-changing and evolving. Therefore, for an SLA to be effective, it cannot follow a write it once and forget it approach, but must be regularly reviewed and updated.

Are Your SLA Targets Tired and Irrelevant?

Perhaps the most important consideration when defining SLAs is identifying targets and measures that are business-relevant. Many well-intentioned efforts at establishing SLAs fall short because the referenced measures have no meaning to the business. For example, “number of calls to the service desk” is important for the support center manager to understand and track. But from the business perspective, the service desk is there to take calls; that’s why the service desk exists. How does my call to the service desk result in business value? Or let’s take average speed to answer (ASA). Again, this one is good for the support center manager to know. But if it’s my call to the service desk that took over 60 seconds to answer instead of the average 25 seconds, all I am is irritated. It doesn’t matter to me that my particular experience was an anomaly.

If it’s these types of operational measures that you’re reporting as part of your SLAs, then you need to elevate your SLAs. Your SLAs can and should be so much more than just capturing measures and producing reports that have no business relevance and no one reads.

How can you elevate your SLAs? How about using the strategic framework?

Enter the Strategic Framework

I described the strategic framework in my article, The Power of the Strategic Framework. A strategic framework is a structured method used to define how a project or initiative supports the key objectives of stakeholders. The foundation for the strategic framework is the mission-vision-goals statement of the company.

So how can the strategic framework help you elevate your SLAs? First, the strategic framework helps with understanding the key objectives of stakeholders. From the perspective of an SLA, the stakeholders are primarily customers (as defined previously). What business goal is the customer trying to accomplish through the use of an IT service? Is it to increase sales by 25% in two years? Is it to introduce two new products by year-end? Or perhaps it is to increase market share by 40% in 3 years. Regardless, the first step in elevating your SLA using the strategic framework is to understand the business goals.

The next step is to identify how that IT service helps the business achieve business goals. What does the IT service deliver or enable that the business can use to accomplish these goals? Using the above examples, what outcomes provided by an IT service will help the business increase sales, introduce new products, or increase market share? In context of the strategic framework, these outcomes become your objectives; in the context of an SLA, these outcomes are the basis for your service level targets.

Now, how can these outcomes be measured in terms that are meaningful to the business? For example, rather than report on service availability (e.g., 98% availability), how about report on a business-relevant measure that reflects availability (e.g., IT provided sufficient availability such that the business was able to exceed its goal of producing over 1000 widgets for the third consecutive month.)? The first example—98%—has little meaning to the business; but business colleagues can immediately relate to the second measure: 1000+ widgets produced for three consecutive months.

Think in Business Terms

Using the strategic framework as a guide to developing SLAs helps IT think in business terms, not in terms of technology or activities. Defining SLAs from this perspective will change the perception of IT from being an “order taker” to a “valuable partner and resource” for the business it serves. 

Doug Tedder is a strategic, innovative, and solutions-driven IT service management professional with more than 20 years of progressive experience across a variety of industries. He’s a resourceful and hands-on leader with track record of success implementing ITSM and IT governance processes. Doug is a certified ITIL Expert and ISO/IEC 20000 Consultant Manager and holds many other industry certifications. In addition, Doug is an accredited ITIL Foundation trainer and HDI Support Center Analyst and Support Center Manager instructor. Follow Doug on Twitter and connect with him on LinkedIn.