Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to build better SLAs for more strategic applications outsourcing

Stephanie Overby | Aug. 24, 2015
Service-level agreements need to not only look good on paper, the must deliver business results in real life. Here’s how to create more effective SLAs for application development and maintenance.

What are the biggest mistakes you see IT buyers make when it comes to selecting SLAs for their deals?
Kirz: Specific SLA problem areas include:

Business alignment. Many customers still don’t take the time to understand the levels of service and performance that the business requires; instead, they use SLAs they find in other deals. Working with the business to understand what SLAs really matter allows customers to focus SLAs (and therefore their providers) on what really matters and better align with business objectives.

Earn backs. Earn backs are a mechanism that allow providers to perform at or above the SLA standard for a fixed amount of time in order to make up for an SLA default. When the earn-back requirement is met, the provider no longer has to pay the SLA credit. Providers are often able to convince customers that earn backs are ‘fair’ or that the provider can agree to more stringent SLAs if there is an earn-back mechanism in place. However, earn backs dilute the incentive for the providers to deliver the resources and process improvements that make SLAs important in the first place.

Inability to measure SLAs. Some customers create SLAs that cannot be measured because the tools with which to perform the measurement are never implemented. Providers should be made responsible for implementing the tools with which to measure SLAs.

Inability to validate SLA performance data. Customers count on providers to measure SLAs rather than relying upon objective tools to automatically capture SLA performance data. This is a mistake; automated tools will provide a more accurate representation of SLA performance and lead to less disagreement.

SLA definition. Providers often edit proposed SLA definitions so that they can more easily meet the SLA. For example, Incident Response Time is an SLA meant to ensure that someone from the provider is addressing an incident within a minimum number of minutes (e.g., 10 minutes). However, some providers meet the SLA 100 percent of the time by putting in place an automatic reply to any email it receives in its incident queue. Customers should carefully define SLAs so that they represent and measure the intent of the service level, not simply the language of the defined term.

SLAs that have never been achieved. Some providers will balk at market-leading SLAs because the SLAs have not been achieved in a customer environment before, and some customers find that position reasonable. Instead, customers should focus on the SLAs their business requires, regardless of whether such SLAs have been achieved in the past, and select providers partly based upon how the providers propose to meet these new levels of service.

SLA exceptions process. Once SLAs are in place, some providers will work hard to create exceptions that ensure the provider never misses an SLA. Customers need robust SLA governance in order to avoid excuses such as changing the levels of incident priority in order to reset the clock, invoking ‘hold time’ as providers wait for clarification, or anything having to do with third-party involvement. 


Previous Page  1  2  3  Next Page 

Sign up for Computerworld eNewsletters.