Everybody\u2019s doing SLAs\u2014service-level agreements. But there\u2019s a lot of confusion about what they are and how to go about doing them. As a result of this confusion, some IT organizations are finding that SLAs do little more than generate a lot of bureaucracy and minimal benefits. \n\nWhat\u2019s this buzzword really about, and what does it take to do SLAs right? \n\nTwo Different AnimalsThe term SLA is being used to refer to two very different things: metrics and internal contracts. \n\nOne meaning is a benchmark of performance that applies to all customers of a given service. For example, an SLA for a given service might promise that it will be up and running 99.999 percent of the time. This is not really an agreement at all. It\u2019s a metric of performance (availability), and a benchmark that defines success on that metric (99.999 percent). Essentially, it\u2019s a dial and the desirable green zone on the dial. \n\nSince it\u2019s not really an agreement, it\u2019s a waste of time (and indeed a nuisance) to ask clients to sign this type of SLA. The IT organization can (and should) establish its own metrics and performance targets without clients\u2019 permission. \n\nA far more interesting definition of SLA is an internal \u201ccontract\u201d between a customer and a supplier for a specific deliverable. This is a very different animal. This type of SLA documents a purchase decision, and certainly requires a commitment (be it an actual signature or a figurative one) from both the customer and the supplier. \n\nLet\u2019s examine this type of SLA further.... \n\nSLA as an Internal ContractAn SLA represents an agreement to sell a service to a customer (e.g., a client in a business unit) for a period of time (e.g., a year). It clarifies the service (IT\u2019s deliverable), including its level of quality (where performance targets are relevant). And it represents an agreement by the customer to pay for the service, albeit in many cases by allotting a portion of the IT organization\u2019s core budget. \n\nIn fact, an SLA is a subset of the broader concept of internal contracts. IT is a business within a business that contracts with clients to \u201csell\u201d (whether or not money changes hands) both products and services. \n\nThe term SLA generally applies only to services, but the broader concept of internal contracts is relevant to both. In practice, all the processes involved apply equally to both. There\u2019s no need to establish one process for service contracts and another separate process for projects (or worse still, a third process for small projects such as repairs). Contracting is contracting; it\u2019s all the same. \n\nInternal contracts are not pages of legal language designed to hold up in court. They\u2019re simply clear documentation of agreements between buyers (i.e., clients) and sellers (IT). \n\nA contract documents the mutual accountabilities that arise from a purchase decision. \n\nBenefits of Internal ContractsContracting is not a waste of time, not a bureaucratic ritual. The minutes spent working out a mutual understanding of both the customer\u2019s and the supplier\u2019s accountabilities at the beginning of a project can save hours of confusion, lost productivity and stress later. Furthermore, contracts are the basis for holding staff accountable for results. They are not wish-lists; they\u2019re firm commitments. IT staff must never agree to a contract unless they know they can deliver results. \n\nInternal contracts also hold customers accountable for their end of the deal. For example, on a development project, clients may have to agree to things like providing their people\u2019s time to work with the development team, negotiating rights to data with other clients and doing acceptance testing. By agreeing on customers\u2019 accountabilities up front, projects won\u2019t be delayed by clients who are surprised by unexpected demands, and IT won\u2019t be blamed if clients hold up a project. \n\nContracts are also the basis for teamwork within the IT organization. A \u201cprime contractor\u201d within IT can get help from peers within the organization by subcontracting for their products and services. Since contracts represent solid commitments, internal subcontractors can be trusted to deliver as promised. This helps overcome the feeling that one has to \u201cown the heads\u201d to get things done. \n\nContracts are also essential to resource governance. Before they\u2019re agreed, a proposed contract is the basis for portfolio management. Portfolio managers review the stack of proposed contracts to decide which IT investments are worthwhile, and agreed contracts decrement their checkbook and isolate remaining discretionary resources. \n\nManagers also need contracts to manage their resources. When a contract is agreed, resources (like staff time) are committed. By tracking these commitments, managers will know when their resources are used up and will not make commitments they can\u2019t keep. \n\nIf you\u2019re going to manage IT in a businesslike manner, internal contracting is essential. \n\nLevel of GranularityIdeally, an internal contract is documented for each distinct purchase decision. No contract is needed when customers aren\u2019t concerned about the supplier\u2019s commitments, and when customers don\u2019t make purchase decisions. (Clearly, there must be no charge for these things.) In general, these are activities that benefit the supplier more than customers, such as the account rep function, proposal development, and building internal capabilities through research and training. \n\nFor services, a contract (SLA) is agreed for each distinct service with each distinct business unit at the beginning of each year. For convenience, a set of service contracts can be bundled and negotiated in one sitting. \n\nEven services that are sold automatically to everyone in the company (e.g., e-mail) deserve a contract. Of course, a standard contract can be developed and negotiated with the company\u2019s executive committee. The value of this mass-market contract is in the clear understanding it creates of exactly what the IT organization is committed to delivering and where its budget is going. \n\nFor projects, a contract is agreed for each stand-alone deliverable. For example, imagine that we\u2019re upgrading a bunch of PCs in the field, and at the same time rolling out a new sales application. Clients could buy the PCs without the application, and the application would work without the PCs. These are two distinct purchase decisions\u2014hence, two separate contracts. Again, they might be bundled and negotiated at the same time for convenience. \n\nFor small projects like repairs and commodity products like shrink-wrap PC software, a \u201cstandard contract\u201d may be developed as a template and applied to each order. The commercial equivalent is the language on a box of software that says something like, \u201cbreak this seal and you\u2019ve made a deal.\u201d \n\nWhy this level of granularity? Each distinct deliverable is a purchase decision made by a customer who has the right to buy it or not (in most cases), the right to decide how much of it and what level of quality he\/she wants, the right to expect results, and the obligation to pay for it (perhaps through the IT core budget). \n\nRemember, even the smallest contract can do a lot of damage if clients expect more than IT has committed to deliver. \n\nWhat Goes in a ContractThere are a limited number of essential elements in any contract (be it an SLA or project contract): \n\n\n\nThe name of the customer. The customer may be a consortium if an identified set of customers wishes to share the purchase of the product. However, \u201cthe whole company\u201d is not a legitimate customer, since it is logistically impossible to get everyone to agree to all the details of the purchase. \n\nThe name of the supplier. \n\nThe product to be delivered or services to be rendered. This defines the specific deliverables, perhaps specified in detail in an attachment. \n\nA one-line description that is the title of the contract, such as the name of the project. \n\nThe start date (a solid commitment, not a \u201ctarget\u201d or \u201cpriority\u201d). This means that a contract cannot be formed until the project is funded and a start date is scheduled. \n\nAn estimate of the elapsed time from the start date required for the project. For service-level agreements, this takes the form of a renewal date. \n\nThe price (even if it\u2019s to be paid out of the IT core budget); and the terms of payment (e.g., fixed price versus time and materials), of renewal and of termination. Whether or not IT charges for its products, it is useful to provide information on the total cost to shareholders of the purchase decision to help customers make wise choices. \n\nThe customer\u2019s accountabilities (e.g., we can only meet this commitment if the customer does this...). The contract should specify a complete list of things the customer must do for the supplier to be successful, plus a best-effort list of things the customer must do to realize the intended benefits. \n\n\n\nRisks and assumptions about other dependencies that are outside of the control of the customer and the supplier (e.g., we can only meet this commitment if the world does this...). This does not include dependence on subcontractors, since that\u2019s within the control of the group issuing the contract. \n\nA minimum of necessary administrative information. Remember, the goal is to be very clear and precise, but to keep it as simple as possible. \n\n\n\nThe Bottom LineSLAs are hardly worth doing if they\u2019re not real internal contracts that document specific purchase decisions. To make internal contracting (including SLAs) work requires some thought. Processes have to be documented that explain the who, when, what and how. Staff require training, including not only the mechanics but also things like how to avoid "bad business" and how to manage time to meet every commitment. A contracts database may be established. And IT account reps should be prepared to broker clear contracts. \n\nSure, establishing the practice of contracting takes a bit of effort, but it\u2019s a very worthwhile endeavor. Internal contracting is the basis for resource management, teamwork, and accountability. Contracting is not just a businesslike way of working. It\u2019s fundamental to the integrity of the IT organization.\n\n\n\n Dean Meyer helps IT leadership teams design high-performance organizations. Author of six books, numerous monographs, columns and articles, he brings innovative systematic approaches to what others consider the \u201csoft\u201d side of leadership. Contact him at email@example.com or visit his website for information that can help you implement these ideas, or with suggestions for other buzzwords to analyze in future columns.