SLAs: A CIO’s Guide to Success

Ronald Lynn suffers the classic irony of the shoemaker whose children go without shoes. His IT group at Inspire Insurance Solutions Inc., an insurance and technology outsourcing company based in Fort Worth, Texas, serves both external outsourcing clients as well as internal Inspire business units. Money talks when prioritizing service calls, admits Lynn, who is executive vice president and CIO at Inspire. “What do you do when your internal people are screaming for help because you’re serving the paying customer instead of them?” he asks.

Lynn and his staff must live by two completely different sets of rules. When his paying customers want more service, they come to the bargaining table. When Inspire customers want more, renegotiating the IT budget is not usually an option. While serving external customers, his staff are revenue generators whose time is money. Internally, they are dedicated “service providers” whose time is undefined—the IT budget clock doesn’t have a minute hand or even an hour hand. Performance is harder to measure and harder to control. “With our external clients, we’re either above or below the performance level that’s set in the contract,” Lynn says. “If we’ve fallen below it there’s a penalty, and if we’re above it we get a few percent back.” He can’t apply the same sorts of penalties and rewards internally because most of his internal customers are fighting the same sort of “service bureau” perception and budget constraints that he is. “If I sign a contract with accounting and I don’t provide the service they want, they can say, ‘Hey, we signed a contract.’ And I can say, ‘Great, I’ll start providing that level of service to you—tomorrow.'”

Bob Quinn, vice president and CIO for computer systems at Sun Microsystems Inc. in Palo Alto, Calif., puts the dilemma even more succinctly: “You can’t sue your own IT department.”

Though CIOs serving internal customers cannot hope to have the same sorts of ironclad contracts that govern outsourcing relationships, the service level agreement, or SLA, is the next best thing. The concept dates back to the ’60s, when IT departments used SLAs to measure technical services like data center uptime, for example. But SLAs have evolved to a new level in the last few years, becoming more broad-reaching and bilateral. These new agreements require IT to work with its business customers to define a short-list of services that are most important to keeping the business running, such as guaranteed e-mail delivery time or the availability of important software applications.

“These SLAs focus on the consumables that end users really consume,” says Dean Davison, senior research analyst for services and systems management strategies in the Los Angeles offices of Meta Group Inc., a consultancy based in Stamford, Conn. “Your customers could care less about ‘router uptime’; they want to know how well the network is performing and whether their people can get their work done.” The business driver is simple: “The business wants to understand what it will pay and what it will get,” says Joachim Frank, worldwide program manager of IT service management in the Munich, Germany, offices of HP Consulting, a Mountain View, Calif.-based division of Hewlett-Packard Co.

The new SLAs are distinguished by their clear, simple language and their tight focus on the needs and wants of the business (see “This Is Not Your Father’s SLA,” Page 58). IT groups that have adopted this clarity strategy have seen improved relationships with customers, better leverage in budget negotiations and an improved ability to compete with outsourcing vendors. Yet despite these successes, only 20 percent to 25 percent of Meta’s IT research clients actively use them, says Davison. The usual excuses of time and money apply. Few IT departments have a clear sense of their own performance levels, so there’s usually much work to be done before real negotiations can begin with the business. Testing or benchmarking IT services costs around $100,000 for each major technology “slice,” such as the data center, desktop services or networking, according to Davison.

SLAs also usually require outside help. Both IT and the business will want an objective outsider to help develop the agreements; that consulting can add another $50,000 per technology slice. Finally, there is the old “simple is hard” conundrum. Boiling down the long list of IT services into a clear, simple short-list takes time and energy—figure on at least three months to a year, even with consulting help.

The work doesn’t stop once all the SLAs are in place, either. The agreements require constant discussion and renegotiation as the needs of the business change. Untended SLAs can lull IT into a false sense of security about the level of existential happiness among its customers. E-mail response time and network availability statistics may look great to IT, but the business may actually be seething about a wholly unrelated issue. To be effective, SLAs require more thoroughness and vigilance in measuring customer satisfaction so that dissatisfaction not reflected in the SLA metrics will reach IT before a real crisis hits.

Yet despite the trouble and expense, SLAs provide invaluable performance metrics to IT and create more informed customers. “The biggest benefit of an SLA in my mind is it makes the business aware that there’s a relationship between support and dollars,” says Tim Parsons, senior vice president for IT at Interstate/Johnson Lane Inc., a brokerage firm based in Charlotte, N.C., that created an SLA for help desk support. “If they can understand the relationship between cost and the level of support, then they can make a better business decision about what support is required and how much it will cost.” Without lining up customer expectations with IT’s ability to realistically meet those expectations, IT stands little chance of breaking out of the first circle of “service bureau hell”: unrealistic expectations matched to limited resources.

What follows are tips and advice, culled from the experiences of committed SLA users, to help clarify the process of defining, implementing and maintaining these new contracts with the business.

Don’t Try to Implement SLAs Across the Board.

“Start the SLA process by saying, ‘Where do I need SLAs the most?’ because doing it across the board sounds like a mandate,” cautions Sun’s Quinn. Quinn uses the Rambo approach, testing SLAs among the SLA skeptics, like engineering. “They know it all, they tend to have the technology background to say, ‘I know you can do what I want,’ but they aren’t living in the practical world in terms of resource management,” he says. These demanding people force Quinn to write bulletproof SLAs.

Meanwhile, George Mellor, vice president of support services for BISYS Networking Services in West Newton, Mass., takes a FOIT, or friend of IT, approach, testing SLAs among people most likely to give IT a break. “We needed a group that would allow us to make some mistakes,” says Mellor. “We picked an IT-friendly and technologically savvy group to work with so we could refine the performance reports and get them into language the users were comfortable with.”

Expectations Can—and Will—Be Outrageous.

Sun’s wandering workaholics often spend 12-hour days slaving away at home or on the road, and they expect IT to fix their broken computers wherever they are. Quinn says talking out these expectations and the resource commitments necessary to meet them is the only way to create SLAs that everyone can live by. “Don’t start with what you in IT think people’s expectations are or should be; start by asking people what are their expectations,” says Quinn. “Because often the expectations are higher than what’s reasonable. People need to understand that pushing IT to service these unrealistic expectations will only drive IT off course.”

Train People to Develop SLAs.

In half-day to one-day internal courses, Sun trains its IT staff to draft and manage SLAs, according to Quinn. Business people receive a less technically oriented two-hour training class. IT engages the business in a process that includes reviewing the current services, getting feedback from users on the services, getting buy-in that they want an agreement, drafting the new SLA, reviewing it, getting feedback and then finalizing it. There is a standard set of SLA documents that each group uses to form the base SLA so that when new SLAs are added, there will be some consistency among the different documents, says Quinn.

SLAs Cannot Exist in a Vacuum.

“We have company IT steering committees at the executive level, the functional or geographic level and the project level,” says Quinn. “The IT executive steering committee oversees the entire company. At that level we’ll come in with a metrics score card that identifies the key aspects of service levels that [the executive] group needs to monitor. We meet with [that group] monthly and review the SLAs each quarter. The functional or geographic steering committees review an SLA score card relevant to infrastructure and their applications at a more granular level than the corporate steering committee. The project steering committees focus on the specific needs of the project. For example, right now we have a big initiative around a flexible sales force and we have specific SLAs on services we provide to that project,” he says.

Be Prepared to Skip Some Areas of the Business Altogether.

“There are certain areas and functions within Sun where we say, ‘We’re just not ready for it here; the relationship isn’t there, the customer satisfaction isn’t there,'” says Quinn. “Some of the engineering areas like lab support are difficult. The engineers’ needs are so variable that we say, ‘We’re going to provide you with a resource pool, and if we get to a point where your service needs are steady, then we will start talking about having SLAs.'”

Good SLAs Are Simple and Few.

Having too many SLAs makes tracking and discussing performance more difficult and tedious. Those all-important meetings with the business to discuss SLAs become long, boring, complex reporting sessions, with less time devoted to more important issues like needs and satisfaction. “I try to keep the list of SLAs with any one group down to less than one page,” says Quinn.

Motivate IT Staff to Live Up to the Agreements.

At Brooklyn, N.Y.-based utility KeySpan Energy Corp., SLAs are tied to the variable component of IT staff salaries. “Once everyone understood this was not another fad and that we were going to tie these SLAs to our own compensation, it became like selling ice cream in the summer,” says Bill Haigney, IT planning consultant for KeySpan. “As for selling it to our own IT staff, once we mapped it directly to the variable bonus program, it got their attention and they were supportive.” The SLA program at the new utility (formed through a recent merger) is still in its formative stages, but there’s no question that it will succeed—the New York State Public Service Commission has mandated that the new utility must identify and quantify the costs of IT services so that customers of the regulated portions of the utility are not paying for services to the unregulated units.

Connect SLAs to Customer Satisfaction.

At Sun, IT surveys its customers randomly so that at least 40 percent respond over the course of a year, says Quinn. To root out unreliable responses, the survey asks respondents to state their understanding of SLAs before they say whether they like them. “We gauge how much they understand the service and then normalize their responses based on their level of knowledge,” he says. “It’s better than generic surveys because [the latter] tend only to get responses from people who are happy or upset and no one else.”

Offer Different Levels of Products and Services for Different Prices.

By dividing an SLA into different performance levels, such as basic, enhanced or premium, for example, CIOs can easily show customers the resource and cost trade-offs required to achieve different levels of support, says Alexandra Whitehead, vice president of the Service Lines Group for Mountain View, Calif.-based research firm G2R Inc. Outsourcing companies are currently using such formulas to reduce the adversarial atmosphere of contract negotiations, she adds. “It makes the CIO prioritize and it makes the vendor explain why it costs more to provide higher levels of service.”

Measuring SLA Performance Must Be Easy and Automated.

Manually tracking SLA performance metrics such as network availability is tedious and prone to error. Also, if someone outside IT—in finance, for example—is calculating the same SLA metrics, the two groups may not agree. Using software tools to automate the measuring process saves time and reduces error and conflict. “If you don’t have the cold, hard facts, the meetings where you talk about performance with the business won’t go well,” says Parsons. “You can’t go in there and say, ‘I think we are meeting the SLA requirements,’ and have someone on the business side say, ‘No, you’re not.'”

All Bets Are Off if the Business Really Wants or Needs Something.

Internal IT groups do not have a true arm’s-length relationship with the business like an outsourcer does, says Scott Maddern, vice president of sales and marketing for Integris, a Billerica, Mass.-based outsourcing company. IT will still have to send someone to the CEO’s office at a moment’s notice to do whatever is necessary to get the computer working again. “The reality is that the SLAs get thrown out the window in these kinds of situations,” says Maddern.

Monitor the Use of Resources as Closely as You Do the SLAs.

Resources such as staff time are an important part of SLA negotiations and the performance measurement process, says Maddern. By setting resource allocations for each SLA—1,000 person hours per month for desktop PC support, for example—IT can monitor the amount of resources applied to the particular SLA and a particular department. The goal is not to limit resource commitments but simply to make it clear who is gobbling up resources, he says. “The CIO is usually forced to spend the extra money to serve the needs of X business unit [no matter what the SLA says]. But then when you go back and discuss costs and services with the business, there’s a tighter correlation between the two.”

SLAs Require Constant Vigilance and Maintenance.

At a big company like Sun, the power and relevance of SLAs ebb and flow with the level of focus that business and IT management devote to them. Over the last two to three years, for example, management’s focus has moved to other things, and the SLA effort has fallen off commensurately. Quinn says that as CIO he has to force SLAs onto the agendas of top business executives at Sun to bring their attention and support back to SLAs and avoid the perception that Sun is “done” with SLAs now that they have been implemented. “We’re at a stage where SLAs are accepted and understood,” says Quinn. “But they don’t maintain themselves. It’s something you have to continually reinforce and maintain.”