Project Management

Members offer tips, advice on improving SLAs

Service level agreements (SLAs) are constantly evolving and becoming more end-to-end in nature, according to industry experts. Yet insight from TechRepublic members shows that common sense is still the CIO's best tool when it comes to SLAs.


Service level agreements (SLAs) aren’t new, but they’re certainly not stagnant. Traditionally, SLAs have measured traffic on backbone networks only, but they’re now incorporating local loops and becoming more end-to-end in nature, according to Liz McPhillips, Probe Research's senior analyst for business services. Probe recently published “Service Level Agreements in North America,” a report by McPhillips.

In addition, service-specific SLAs are beginning to appear. For instance, voice over Internet protocol (VoIP) SLAs, which measure jitter, packet loss, and call completion rate, are now available. Yet, as Phillips notes, it’s still difficult to extract individual user statistics from networks that accommodate hundreds of clients.

Despite that continuing hurdle, current SLA trends bode well for CIOs in their efforts to improve client service. However, the effectiveness of an SLA still depends on how effectively a CIO negotiates and enforces the agreement. We queried TechRepublic members to get their insight and advice on how tech leaders can best optimize that next SLA in light of the new trends. They offered the following tips, based on their experiences with SLAs.

Base compliance on real world, not technical, criteria
The best SLA is one that even nontechnicians can easily understand. TechRepublic member Dale McAllister, an IT professional working in Beijing, China, advises that “instead of network availability, use e-mail access availability….This ensures that all aspects of the service are in tune and satisfying [to] the customer instead of being technically correct and completely frustrating to the customer.”

Use penalties as tools
There’s no way that an SLA penalty can make up for the damage that a failed system causes. Will rebates heal an enterprise’s damaged reputation? Will they make up for customers lost to a competitor? Of course not. So, instead of viewing penalties solely on a punitive basis, you should use them strategically to extract better performance from the service provider.

“If an ISP tells you they'll give you 100% availability, you know you are not going to get that,” notes McPhillips. “However, if there are high penalties for this failing, then they are in a position that they will do their best to keep the backbone up and running, and they will correct problems as quickly as they can,” she adds.

Treat the SLA as a sophisticated contract
SLAs are highly specific and sophisticated legal documents. CIOs should treat them that way. “Make sure that the scope of the SLA, the customer and supplier responsibilities, performance measures and reporting, support and escalation procedures, and remedies for nonperformance are all clearly defined to your satisfaction,” advises TechRepublic member Chris Elmes, IT manager for Cotswold Outdoor Ltd., a UK-based retailer of outdoor clothes and equipment. “If you don't understand anything 100%, don't be afraid to ask until you do—after all, it's your reputation that will get damaged by a badly implemented SLA covering a service that is not performing,” Elmes adds.

Technology and business conditions change quickly
Make sure your SLA can change as technology and business conditions change. Leendert Stuyt, the chief of help desk operations for an Air Force Reserve unit in the Midwest, explains that SLAs can dictate actions that happen far in the future. He notes that the gear that actually will be used in the future might have been updated in the interim. It’s important to account for such updates, yet it can be hard to do. For instance, the enterprise may want to use an OS that is released between the writing of the SLA and actual installation. This has ripple effects—you must take care to ensure that the hardware agreed to in the SLA can support the new OS. It’s also likely that the staff training stipulated in the SLA will need to be changed.

Communications is the key to hitting all the relevant elements. “If nothing else,” notes Stuyt, “the SLA people are usually manpower folks or resource management folks. They should sit down with the tech folks or a least get a draft [of the inventory] to them.”

Companies change—and sometimes go out of business—between the signing of an SLA and the implementation of its provisions. Timothy Holm, a TechRepublic member and project manager for the Minnesota Department of Agriculture’s IS division, knows the potential scenario all too well. In one instance, a project supplier was originally slated to provide help desk and application support. When the time came, the company was unable to comply. A reasonable amount of change must be expected and dealt with in the SLA, says Holm, who recommends mandated six-month reviews.

Three’s a crowd
Vendors often treat third-party equipment and services as exceptions to a SLA. CIOs need to keep a close eye on this sort of thing, notes Elmes, as it can be used as a way to shirk responsibilities. The key is to study the agreement closely.

“As far as possible, make sure that it covers your needs end to end, and where it cannot (e.g., [where] there is a reliance on a third party for communications), make sure you know where responsibilities lie,” says Elmes. “Also, try to understand any third-party influences that may affect performance against [the] SLA, as these are likely to be included as exceptions that you cannot claim against and the supplier may use these areas to avoid some responsibility for failure,” Elmes adds.

Be able to say goodbye
It’s important to include language in the SLA that will enable you, the customer, to break free. These stipulations should cover at least three things—service changes, catastrophic meltdowns (even if they are one-time affairs), and chronic bad performance.

“After the number of bankruptcies and mergers recently, many customers are demanding exit clauses in their SLAs, to make it easy to get out of the contract in the case of a change in service policy,” explains McPhillips. She also recommends that customers write provisions into the contract stipulating that if SLAs are violated several months in a row, the client can break the contract without penalty.

Make credit for noncompliance automatic, not a hassle
It’s a good idea to put the onus on the vendor, notes McPhillips. “Customers…want proactive SLAs—i.e., if their guarantees are not met, they are automatically credited at the end of the month, without the need to make several phone calls [and do other things] to receive their credit. At present, only a few providers offer this.”

Adjust for international differences
Many enterprise users operate across international boundaries. It’s important to standardize SLAs as much as possible between countries. The most significant variable, says McAllister, is the cost of time, which differs due to different labor rates and cultures.

McAllister has a straightforward formula to address the issue: “We settled on a relatively simple approach to manage the key variations. [We] clearly define the responsibilities [and] clearly and simply define the way the responsibilities will be measured (in the language of the user), then agree to the cost as a standard. Then, as we implement the same services across countries, we index adjustments to the SLA against adjustments to the costs. In this way, we were able to implement standard services and SLAs that were flexible enough to compensate for the differences in cost of time.”

The best tool is common sense
While the provided guidance offers good advice, respondents also stressed that the CIO’s best tool for carving out an SLA is common sense.

“The SLA is a living document that needs attention in order to be useful, and sometimes [it] can bring an errant project or customer back to the negotiated baseline,” says Holm.

Editor's Picks