Why service level agreements are dead

If you’re like many CIOs, the chances are your company compensates third-party IT service providers for something they didn’t do or pays them twice for something. Technology leader Nipa Chakravarti realized that’s what was happening at TransAlta (Canada’s largest publicly traded power generator and provider of renewable energy). I recently talked with Nipa, and she made an interesting comment: “I want to move away from SLA-driven contracts.”

As Nipa explained in a prior blog post, she successfully restructured TransAlta’s IT group to be more responsive to business needs, doing the things that the business users care about and doing them in a reasonable time frame and cost point. As detailed in that blog, she dramatically changed the value equation for IT at the company, making it much more cost-effective, achieving results much faster and at the same time delivering higher quality and more reliable work. That’s quite a formidable set of accomplishments. So it’s worth paying attention to her strategies for taking the organization to the next level.

Two significant problems with SLA contracts

A key component in her strategy is rethinking the role of service level agreements (SLAs) within her organization and with third-party service providers. Why? As Nipa told me, “When we have an SLA contract, the service providers just meet the service levels. That’s what they do. But that’s a problem. They don’t meet our rapidly changing needs; they just meet the service levels, stipulated in the contracts.”

Over time, SLAs drive behaviors that are focused on delivering a minimum level of service at minimum cost to the provider. This forces IT organizations to become a commodity and not a strategic, value-added partner to the business. SLAs by their very nature are established as achievable contractual targets and can be static over time. Misused, they can be counter-intuitive to driving business agility and pace. 

There is little reason to innovate in an SLA arrangement. If it isn’t broken, why fix it? She shared an example of the situation with their infrastructure managed-services provider. The SLA contract has metrics around uptime, performance and other metrics. Although the vendor is admirably meeting the SLA standards today, there is little incentive to dramatically shift the IT organization to keep pace with rapidly changing business requirements.

The company also invested in technology. The issue is she no longer believes the provider should get credit/payment for meeting those SLAs because her company invested in process redesign, automation, behaviors that allow them to get in front of issues and eliminating the bugs and variables in the infrastructure environment to make it reliable. They addressed the issues and stabilized the environment. So now it’s easy and routine to meet those SLAs.

Therefore, paying the provider based exclusively on meeting SLAs means paying for results that are sub-optimal and over time erode the benefit of a managed-services arrangement. And in areas where the provider’s services included also investing in stabilizing the environment, paying the provider for meeting SLAs means the provider, by design, is paid twice.

“Meeting the SLAs is no longer our concern,” Nipa explained. “Basically an SLA contract says the provider’s performance is good enough when meeting the SLAs. But good enough isn’t what we want to buy. We want to stop the issues from happening in the first place. We want to pay the provider for success in improving our environment.”

But the criteria around “success” changes over time, especially with the pace of change in technologies and business models. Nipa stated, “Our first struggle for success was stabilizing the environment. But once it’s stabilized, that’s no longer a measure of success. We have to continuously drive towards right-sizing technology services to business need. The IT world is changing; and now I need, and our business partners need, agreements with providers that help us evolve more than meeting basic performance requirements.” SLAs around uptime and reliance don’t matter when measuring for success where the focus is on speed and value.

SLAs are the wrong contract governance vehicle

Service level metrics are worthy targets. They set the bar for a provider’s performance. But once the provider can consistently achieve those targets, the SLAs just represent yesterday’s problems and their importance diminishes. This is especially the case in infrastructure services. SLA contracts just live on past successes and don’t incentivize stretching forward to improve the environment or processes.

As she rethinks the role of service levels within her organization and with third-party service providers, Nipa recognizes that service level metrics are usually time based (such as how quickly an agent can close an issue). But time-based metrics drive a different type of service behavior than a metric based on quality and business outcomes.

The bottom line of SLA contracts

SLA contracts are the wrong governance vehicle and shouldn’t drive a services relationship. Unless you keep moving the SLA’s bar to align with your current goals for “success,” an SLA contract wrongly articulates what your business wants the provider to work on and achieve.

As CIO, you need to move your organization towards a defined “business expectation” model. These expectations allow the business to express targets that match IT delivery models to business outcomes. It may not be unreasonable for a business-critical service to expect 24/7 or 100 percent availability 100 percent of the time; but there may be other services that need much less than the 99.9 percent availability level. Expectations and requirements can change often, so your IT group must be in a position to adapt.

A model based on business expectation allows IT to focus on providing solutions that are the best fit for the business vs. a best-in-class technology team. In today’s economic realities, best in class is often the most expensive option. A “best-for-business” expectation allows a balanced approach to performance and cost or value creation. These decisions are always made in partnership between business and IT.