How to build better SLAs for more strategic applications outsourcing

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.

1 2 Page 2
Page 2 of 2

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. 

What should customers keep in mind in order to develop a strategic set of SLAs that take into account the complexities of application development and maintenance (ADM)?

Kirz: Customers need to keep in mind that ADM services are on a continuing path away from staff augmentation and are moving towards outcome-based solutions (or managed services). With this comes a need to move to a portfolio of service-level metrics that align with the service delivery model. This may mean redefining metrics and adjusting priorities. Customers should be prepared for this and drive these conversations with their service providers so that they can deliver the increasing demands of internal stakeholders.

First, SLAs that can and should apply to staff augmentation work. Any provider-controlled staff augmentation can and should have an SLA (for example, time to onboard resources or turnover).

Second, SLAs for maintenance are very different from those in development. Each area of work should have its own set of SLAs, amount at risk, and credit point pool.

Third, SLAs must continuously improve over time. Customers either don’t include clauses that ensure SLAs continuously improve or allow providers to dictate the statistical methodology that allows for only minor improvements year over year. Instead, customers should include language that ensures SLAs will improve every year.

What are some effective ADM SLAs that IT leaders should consider?

Kirz: In staff augmentation, metrics-centric SLAs that focus on staff onboarding, attrition, productivity and coding quality tend to work well. For managed services, we like to see metrics that align with expected outcomes—for example, ticket resolution timeframe, batch process effectiveness, application availability and customer satisfaction. More importantly, customers should recognize that most deals have both managed services and staff augmentation components so a comprehensive metric portfolio is key.

In application development—beyond the standard SLAs—customers should also consider including SLAs that manage change management compliance, functional specification compliance, and how far in advance of release are all defects resolved.

In application maintenance, beyond the standard SLAs, customers should also consider including SLAs that manage the speed of root cause analysis, synthetic transaction time, and number of re-opened tickets.

Copyright © 2015 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 secrets of successful remote IT teams