Service Level Agreements

Everybody’s doing SLAs—service-level agreements. But there’s 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.

What’s this buzzword really about, and what does it take to do SLAs right?

Two Different Animals

The term SLA is being used to refer to two very different things: metrics and internal contracts.

One 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’s a metric of performance (availability), and a benchmark that defines success on that metric (99.999 percent). Essentially, it’s a dial and the desirable green zone on the dial.

Since it’s not really an agreement, it’s 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’ permission.

A far more interesting definition of SLA is an internal “contract” 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.

Let’s examine this type of SLA further….

SLA as an Internal Contract

An 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’s 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’s core budget.

In 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 “sell” (whether or not money changes hands) both products and services.

The 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’s 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’s all the same.

Internal contracts are not pages of legal language designed to hold up in court. They’re simply clear documentation of agreements between buyers (i.e., clients) and sellers (IT).

A contract documents the mutual accountabilities that arise from a purchase decision.

Benefits of Internal Contracts

Contracting is not a waste of time, not a bureaucratic ritual. The minutes spent working out a mutual understanding of both the customer’s and the supplier’s 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’re firm commitments. IT staff must never agree to a contract unless they know they can deliver results.

Internal 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’s time to work with the development team, negotiating rights to data with other clients and doing acceptance testing. By agreeing on customers’ accountabilities up front, projects won’t be delayed by clients who are surprised by unexpected demands, and IT won’t be blamed if clients hold up a project.

Contracts are also the basis for teamwork within the IT organization. A “prime contractor” 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 “own the heads” to get things done.

Contracts are also essential to resource governance. Before they’re 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.

Managers 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’t keep.

If you’re going to manage IT in a businesslike manner, internal contracting is essential.

Level of Granularity

Ideally, an internal contract is documented for each distinct purchase decision. No contract is needed when customers aren’t concerned about the supplier’s commitments, and when customers don’t 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.

For 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.

Even 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’s 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.

For projects, a contract is agreed for each stand-alone deliverable. For example, imagine that we’re 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—hence, two separate contracts. Again, they might be bundled and negotiated at the same time for convenience.

For small projects like repairs and commodity products like shrink-wrap PC software, a “standard contract” 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, “break this seal and you’ve made a deal.”

Why 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).

Remember, even the smallest contract can do a lot of damage if clients expect more than IT has committed to deliver.

What Goes in a Contract

There are a limited number of essential elements in any contract (be it an SLA or project contract):

• The 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, “the whole company” is not a legitimate customer, since it is logistically impossible to get everyone to agree to all the details of the purchase.
• The name of the supplier.
• The product to be delivered or services to be rendered. This defines the specific deliverables, perhaps specified in detail in an attachment.
• A one-line description that is the title of the contract, such as the name of the project.
• The start date (a solid commitment, not a “target” or “priority”). This means that a contract cannot be formed until the project is funded and a start date is scheduled.
• An 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.
• The price (even if it’s 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.
• The customer’s 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.
  • Risks 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’s within the control of the group issuing the contract.
  • A minimum of necessary administrative information. Remember, the goal is to be very clear and precise, but to keep it as simple as possible.
  The Bottom Line

  SLAs are hardly worth doing if they’re 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.

  Sure, establishing the practice of contracting takes a bit of effort, but it’s 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’s fundamental to the integrity of the IT organization.

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 “soft” side of leadership. Contact him at dean@ndma.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.