CHAPTER 5
Service Level Agreement
Let’s assume you are setting up the maintenance of an IT system currently being implemented by a separate development project team. If the project team uses project management’s best practices, it would have a scope statement, project charter, and project requirements. But don’t be confused; the development project’s project charter authorizes only the work for the development of the system. It does not authorize ongoing maintenance. The project charter and other scope documents can be retained by the maintenance team, but only for historical purposes. A different document is needed to authorize the maintenance team to proceed.
The Service Level Agreement (SLA) is the controlling document that addresses maintenance scope and authorizes the effort. The SLA serves as a contract between the IT maintenance team and the business owner of the system. This document must address all the services to be provided by the IT maintenance team in terms that the business will understand. Two ways to provide clarity and eliminate confusion in the SLA are to:
1. List the services that will not be provided.
2. Articulate the responsibilities that the business bears.
When considering the scope of the service, also identify the constraints under which the maintenance team will operate. One of the major constraints is the way the system itself was designed and built. Neither you nor the customer should expect that the maintenance team can make the system do something it was not designed to do without investing in major enhancements.
Separate Enhancements
Companies throughout the business world have recently been decreasing the amount of money spent on maintaining IT systems in an attempt to stay competitive in the marketplace. They spend big bucks on projects to implement new IT systems to gain increased competitive advantage. However, when the project is complete, these companies do not want to keep paying for incremental improvements that do not provide noticeable business benefits. The typical users of the new IT systems, however, want the systems enhanced so that they’re easier to use and have functionality that may have been rejected for funding during development.
You must diligently and effectively manage the tension between these two poles in order to prevent business value loss. When the business leadership decided on IT system functionality, it carefully weighed functionality and cost. You, the IT maintenance manager, must understand these decisions and become the guardian of business value. Requests will most likely come from lower-level businesspersons. You must challenge the enhancement requester if what is being asked for is contrary to the project development criteria that business leadership approved when the project was initiated. To effectively handle the task of protecting the business value of IT systems, you will have to provide the business decision makers with more information about time and money expenditures so that they can verify that their system functionality and cost ratio is still appropriate. To provide this transparency, separate maintenance into base maintenance and enhancements in the SLA. Base maintenance includes any activity to keep the system running: bug fixes, backups, and checking logs. Enhancements are any changes to the system’s functionality due to requirement changes. This separation should be spelled out in the SLA and reported in the ongoing status reporting. In this way, the business can compare the cost breakdowns of just keeping the systems running and of enhancing the systems. Do not assume that the appropriate business owner’s approval of the enhancements means that they are also keeping track of the overall cost of the enhancements. If they are not aware of the overall costs, they may be in for a rude awakening down the road.
To further clarify the separation of bug fixes and enhancements, you can divide the work into two SLAs. The first SLA will focus on base maintenance to keep the as-built systems running, including bug fixes, monitoring performance, and backups. The second SLA will focus on enhancements. Some enhancements can be defined in the SLA, if they’re known at the time, and projected estimates on future work can also be included. If the business customer has a need to drastically cut the budget, you can offer the enhancement SLA as a suitable choice.
Value Position
The purpose of maintaining any system is to continue achieving business value. The business has certain goals and needs. But there is a cost to the business for this maintenance. The team that maintains the system should provide the best value for this ongoing cost.
When going through this book, think about what value you (as a manager) and your team can provide to your business customer. It is fair for the business to ask, “Can another source provide better, cheaper maintenance?” You should never assume you have the right to provide the service and then neglect the customer because you know that the customer must use internal resources like your team. Outsourcing IT is a growing business practice that’s attracting the attention of many executives. To compete with outsourcing, you need to craft a Value Position for your service.
A Value Position presents the clear objectives and operating principles that will benefit the customer. To prepare a Value Position, you must view your service from the customer’s perspective. The Value Position may be related to cost (e.g., a commitment to decreasing the costs each consecutive year), to quality (e.g., using stricter metrics each consecutive year that the maintenance team must meet), or to scheduling (e.g., delivering enhancements faster). Creating a Value Position is not a trivial task, and the effort you expend on it will be well worth the trouble, because you will be leading the customer to think about exactly what benefits will accrue to the business unit from using your service.
After you create the Value Position, you must sell it to the business. Selling is not necessarily one of the most enjoyable tasks for many managers, but it is a supremely important one. What is obvious to you may not be obvious to the business customer. You also need to create opportunities to present your Value Position to different levels of the business by raising the subject at regularly scheduled business meetings or by setting up specific meetings. And you need to include your Value Position in the SLAs. Be sure to listen closely to the response of the customer and to modify your Value Position if necessary.
Keep the following in mind when selling to the customer:
• Leverage the relationships that you have already established with the customer.
• Leverage baseline code and limit customization to only high business needs.
• Identify any quick deliverables you can provide the business after the agreement is in place to show your ability to deliver.
You must, of course, ensure that your team actually delivers this Value Position. Part III, “Executing Service Processes,” and Part IV, “Controlling Processes,” address how to meet your commitments.
Writing the SLA
Before writing your SLA, read all of the chapters in this book. Useful information that is not included here appears in the other chapters related to the SLA, including Chapter 6, “Service Breakdown Structure;” Chapter 11, “Work Tracking;” Chapter 12, “Customer Care;” Chapter 13, “Incidents, Defects, & Enhancements;” and Chapter 15, “Metrics—Overall Control.”
Figure 5-1 provides a suggested outline for an SLA, and the remainder of this chapter describes the sections. This SLA example is a starting point, but it is not a one-size-fits-all version. It will be up to you and your organization to develop an appropriate version for your organization. Since the SLA is the contract that provides the measure your team will be judged against, you need to be sure it’s accurate and complete. You must obtain input from the business and work closely with it as you create your SLA.
Let’s now fill out each section of the SLA in Figure 5-1. The Maintenance Machine presented in the previous chapter serves as an excellent checklist of possible services that your team may provide. The numbers used in the following instructions for completing each section of the SLA correspond to the section numbers of the SLA example in Figure 5-1:
1. Service Level Agreement Parties and Term of Service
State the parties to the agreement and the appropriate approvers (include their signatures).
2. Purpose of Agreement
State the purpose of the agreement. You can modify the statement to suit your organization’s needs, but it can be a very general statement.
3. Overview of Maintenance
Present an overview of how maintenance will be performed—using business terms.
4. Constraints of Maintenance
State the constraints under which the maintenance team will perform its responsibilities, as described earlier in this chapter.
5. Service Activities Included and Excluded
List the services to be provided in table format. For greater clarity, also list services that the business itself is expected to provide and services not performed by the IT maintenance team under this agreement.
6. Severity Level Definition
List any definitions related to the service. For example, including the definitions of the levels of severity of incidents can help the customer to place incidents in the proper category when making requests for service.
7. Maintenance Team Contact Information & Escalation
List your team’s contact information and any further action the customer should take if there is a problem with the primary contact point. Include the contact information necessary for such further action (e.g., help desk phone numbers, group pager numbers, and manager’s phone numbers or pager numbers).
8. Incident Response Time
List the response times your team is committing to, based on the severity level; a critical incident should generally be addressed with greater promptness than a moderate incident.
9. System Components Included and Excluded
List the IT system components that are included and excluded from the agreement and which of the services in Section 5 of the SLA example will be applied to each component that is included. Take care to use terms and breakdowns that the customer will understand.
10. Metrics
List the metrics that will be reported, the reporting frequency, and the target level that your team will strive to meet. See Chapter 15, “Metrics—Overall Control,” for more information.
11. Cost
List the cost with enough detagil to be useful to the customer. See Chapter 7, “Cost Estimate,” for more information.
Figure 5-1: Service Level Agreement
After the SLA is drafted and reviewed by appropriate IT leadership, you must present it to the appropriate business leader. When you do this, you should also review your Value Position and negotiate any concerns that may arise about the service and cost. Getting the customer’s involvement early in the process of drafting the SLA can help establish buy-in and aid you in correctly focusing the document. Take special care to avoid a dysfunctional situation in which an adversarial mentality develops in one or both parties.
How to Judge the Quality of an SLA
So how do you judge the quality of a SLA? The simple answer is, “An SLA is good if it provides useful service and cost information to both the business and IT maintenance.” But more details of what is meant by “useful” are called for.
The SLA should be thought of as process instead of just a simple document. The SLA document represents a contract between the business customer and IT, while the process for developing a quality SLA involves converging what the business needs and what IT will deliver into a common, well-documented understanding.
Attributes of a quality SLA process include:
1. IT consulting with the business before starting to draft the SLA.
2. SLA listing all services to be delivered so that someone unfamiliar with the maintenance team or the business would know what to deliver.
3. SLA listing useful metrics that represent all of the business’s important concerns.
4. IT presenting the completed SLA and Value Position at a face-to-face meeting with the appropriate business approvers.
5. IT creating the Value Position in the form of a slide deck that is easily understood and addresses all the business’s interests.
6. Understanding on the part of the business of what it is paying for.
7. Understanding on the part of the business of the limits of the service.