IT Management Reference Guide

This section presents some helpful tips on how to generate service-level agreements (SLAs) that are mutually beneficial to both the IT department offering them and the user department that monitors them. The initial discussion traces the evolution of IT departments into service organizations. It's important to understand how IT evolved into its service orientation of today, and how SLAs became a natural progression of this advancement. The second part of this section presents helpful tips on how to develop effective SLAs. The final portion explains the important steps to follow when negotiating SLAs.

How IT Departments Evolved into Service Organizations

Most IT organizations began as offshoots of their company's accounting departments. As companies grew and their accounting systems became more complex, their dependency on the technology of computers also grew. The emphasis of IT in the 1970s was mostly on continually providing machines and systems that were bigger, faster, and cheaper. During this era, technological advances in IT flourished. Two factors led to very little emphasis on customer service.

First, in the 1970s the IT industry was still in its infancy. Organizations were struggling just to stay abreast of all the rapidly changing technologies, let alone focus on good customer service. Second, within most companies the IT department was the only game in town, so to speak. Departments that were becoming more and more dependent on computers—finance, engineering, and administration, for example— were pretty much at the mercy of their internal IT suppliers, regardless of how much or how little customer service was provided.

By the 1980s, the role of IT and customer service began changing. IT was becoming a strategic competitive advantage for many corporations. A few industries such as banking and airlines had long before discovered how the quality of IT services could affect revenue, profits, and public image. As online applications started replacing many of the manual legacy systems, more and more workers became exposed to the power and the frustration of computers. Demand for high availability, quick response, and clear and simple answers to operational questions gave rise to user groups, help desks, service-level agreements, and eventually customer service representatives, all within the confines of a corporate structure.

Good customer service was now becoming an integral part of any well-managed IT department. By the 1990s, most users were reasonably computer literate, PCs and the Internet were common fixtures in the office and at home, and the concept of customer service transitioned from being hoped for to being expected. Demands for excellent customer service grew to such a degree in the 1990s that the lack of it often led to demotions, terminations, and outsourcing.

IT had evolved from a purely accounting and technical environment into a totally service-oriented environment. This transition caught many IT professionals off guard. Their traits and specialties consisted mostly of technical skills. They had little to offer in the area of interpersonal relations and customer service. Companies hiring IT professionals today often look for traits such as empathy, helpfulness, patience, resourcefulness, and being team-oriented as requirements for the job. The extent to which these traits are in evidence frequently determines an individual's or an organization's success in IT today.

A natural progression of this trend toward greater customer service was the development of service-level agreements.

Tips for Developing Effective Service-Level Agreements

Following are six tips to help in developing effective service-level agreements. Some of these suggestions, such as the use of penalties, are more applicable to some IT environments than to others. The judicious use of these recommendations should result in SLAs that can be mutually agreed upon.

• Make it understandable. One of the first things that turns off a customer to an SLA is poor writing, technical jargon, and phrases only an IT professional would understand. Make sure that your wording is clear, concise, and understandable.

• Insist on reasonableness. Managing customer expectations is one of the key benefits of an SLA. Expectations need to be reasonable from the standpoint of both parties. Failure to agree on the reasonableness of customer expectations should be escalated to both parties' management.

• Use meaningful metrics. Include service metrics that are meaningful to both IT representatives and customers. These metrics are the basis for determining whether target levels have been met, and should be precise enough as to remove ambiguity and clear enough to be easily understood.

• Keep it brief. Short, straightforward sentences work best. Some of finest SLAs written have only been a page or two long.

• Consider use of penalties. This principle normally applies when chargeback systems are used. Creative individuals employ penalties for IT departments not meeting their service targets even if a chargeback system is not in use. These penalties may be in the form of reduced costs to customers of new projects, reduced bonuses for IT personnel, or adjusted maintenance fees from suppliers.

• Maintain regular reviews. IT representatives and their customers should review their SLAs periodically. For most shops, this is done at least annually, though some perform this review on a quarterly basis.

Steps To Negotiating Worthwhile Service-Level Agreements

The issue of reasonable expectations is a salient point and cuts to the heart of sound customer service. When IT people started getting serious about service, they initially espoused many of the tenets of other service industries. Phrases such as the following were drilled into IT professionals at many companies embarking on a commitment to customer service:

• "The customer is always right."

• "Never say no to a customer."

• "Always meet your customers' expectations."

As seemingly obvious as these statements appear, the plain and simple fact is that rarely can you meet all of the expectations of all of your customers all of the time. The more truthful but less widely acknowledged fact is that customers sometimes are unreasonable in their expectations. IT service providers may actually be doing more of a disservice to their customers and to themselves by not saying no to an unrealistic demand. This leads to the first of two universal truths about customer service and expectations.

An unreasonable expectation, rigidly demanded by an uncompromising customer and naively agreed to by a well-intentioned supplier, is one of the major causes of poor customer service.

This scenario occurs time and again within IT departments throughout various industries. In their zest to please customers and establish credibility for their organizations, IT professionals agree to project schedules that cannot be met, availability levels that cannot be reached, response times that cannot be obtained, and budgets that cannot be reduced.

Knowing when and how to say no to a customer is not easy, but techniques are available to assist in negotiating and managing realistic expectations. While heading an extensive IT customer service effort at a defense contractor, I developed with my team a simple but effective methodology for negotiating and managing realistic customer expectations. The first part involved thorough preparation of face-to-face interviews with selected key customers, and the second part consisted of actually conducting the interview to negotiate and follow up on realistic expectations. Changing the mindset of IT professionals can be a challenging task. We were asking them to focus very intently on a small number of customers when for years they had emphasized doing almost the opposite. The criteria helped immensely to limit their number of interviews to just a handful of key customers.

Getting the IT leads and managers to schedule the interviews was even more of a challenge for us. This reluctance to interview key customers was puzzling to our team. These IT professionals had been interviewing many new hires for well over a year and had been conducting semiannual performance reviews for most of their staffs for some time. Yet we were hearing almost every excuse under the sun as to why they could not conduct a face-to-face interview with key customers. Some wanted to conduct it over the phone, some wanted to send out surveys, others wanted to use email, and many simply claimed that endless "phone tag" and schedule conflict prevented successful get-togethers.

We knew that these face-to-face interviews with primary customers were the key to successfully negotiating reasonable expectations that in turn would lead to improved customer service. So we looked a little more closely at the reluctance to interview. What we discovered really surprised us. Most of our managers and leads believed that interviews could easily become confrontational unless only a few IT-friendly customers were involved. Many had received no formal training on effective interviewing techniques and felt ill-equipped to deal with a potentially belligerent user. Very few thought that they could actually convince a skeptical user that some of their expectations may be unrealistic and yet still come across as being service-oriented.

This turn of events temporarily changed our approach. We immediately set up an intense interview training program for our lead and managers. It specifically emphasized how to deal with difficult customers. Traditional techniques such as open-ended questions, active listening, and restatements were combined with effective ways to cut off ramblers and negotiate compromise, along with training on when to agree to disagree. We even developed some sample scripts for them to use as guidelines.

The training went quite well and proved to be very effective. Leads and managers from all across our IT department began to conduct interviews with key customers. From the feedback we received from both the IT interviewers and our customers, we learned what the majority felt were the most effective parts of the interview. We referred to them as validate, negotiate, and escalate:

• Validate. Within the guidelines of the prepared interview scripts, the interviewers first validated their interviewees by assuring them that they were, in fact, key customers. They then told the customers that they did indeed critically need and use the services that we were supplying. Interviewers then went on to ask what the current expectations of the customers were for the levels of service provided.

• Negotiate. If customers' expectations were reasonable and obtainable, the parties discussed and agreed on the type and frequency of measurements to be used. If the expectations were not reasonable, negotiations, explanations, and compromises were proposed. If these negotiations didn't result in a satisfactory agreement, as would occasionally occur, the interviewer would politely agree to disagree and then move on to other matters.

• Escalate. After the meeting, the interviewer would escalate the unsuccessful negotiation to his or her manager, who would attempt to resolve it with the manager of the key customer.

The validate/negotiate/escalate method proved to be exceptionally effective at negotiating reasonable expectations and realistic service levels. The hidden benefits included clearer and more frequent communication with users, improved interviewing skills for leads and managers, increased credibility for the IT department, and more empathy of our users for some of the many constraints under which most IT organizations work. This empathy that key customers were sharing with us leads me to the second universal truth I embrace concerning customer service and expectations:

Most customers are forgiving of occasional poor service if reasonable attempts are made to explain the nature and cause of the problem, and what is being done to resolve it and prevent its future recurrence.

As simple and apparent as this principle may sound, it still amazes me to see how often this basic concept is overlooked or ignored in IT organizations. I have known managers who believed that customers would be more upset if told the honest details of an outage. One operations manager with whom I worked was especially candid. He shared with me his belief that telling his customers an operator error caused a lengthy outage would reflect badly on him for not training his staff better. In my many years of infrastructure management, I have yet to experience a customer who didn't appreciate a truthful explanation of what went wrong, and how we planned to prevent a recurrence.

Customer-Centric Versus Systems-Centric Service-Level Agreements

A service-level agreement can be either customer-centric or systems-centric. A customer-centric SLA is directed toward one major customer department such as human resources, payroll, engineering, or marketing, and covers all of the applications used by that business unit. The business unit in question usually recommends the scope of the SLA based on the variety and criticality of applications covered in the agreement. For example, the engineering department at one aerospace company used only a few highly sophisticated software applications and entered into an SLA with its IT department that represented all engineering users. A different aerospace firm had specialty engineering groups that required separate SLAs for the various kinds of engineering disciplines. The head of the user department or a suitable user representative normally signs the SLA in partnership with a representative of the IT department. Many IT groups now have customer service representatives for specific business units that serve as signatories for SLAs.

A systems-centric SLA involves a single application, usually an enterprise resource planning (ERP) system such as corporate financials, timekeeping, or employee benefits, regardless of the variety of business units that may use it. While less common than a customer-centric SLA, companies running ERP systems such as SAP, Oracle, or PeopleSoft often use this kind of service agreement. The IT manager responsible for the support of the ERP in question usually signs the SLA as the IT representative along with the CIO. The user departments that use the ERP system the most normally sign the SLA as the user representatives. The number of user signatures can vary from one or two up to eight or ten. In this case, service metrics are distributed to each of the user departments signing the document.

Sample Service-Level Agreement

The following figure shows a sample of a customer-centric SLA.

Figure 1

References

You Can Negotiate Anything (Bantam, 1982), by Herb Cohen.

Getting to Yes: Negotiating Agreement Without Giving In, Second Edition (Penguin, 1991), by Roger Fisher, et al.

IT Systems Management: Designing, Implementing, and Managing World-Class Infrastructures (Prentice Hall PTR, 2002, ISBN 013087678X), by Rich Schiesser.

IT Services: Costs, Metrics, Benchmarking, and Marketing (Prentice Hall PTR, 2000, ISBN 0130191957), by Anthony F. Tardugno, Thomas R. DiPasquale, and Robert E. Matthews.

Trump: The Art of the Deal (Random House, 1987), by Donald J. Trump and Tony Schwartz.