By: Bob Anderson
Director Process Development and Quality Assurance
Computer Aid, Inc.
Over a career in Information Technology spanning multiple decades, I have observed that many IT organizations have focused process improvement and measurement almost exclusively around software development projects. This is understandable due to the business critical nature and costs involved in large software development projects. We have seen how software development process models like CMMI and Prince2 significantly improve business alignment, quality, and timeliness in delivery of software projects.
Though many IT organizations have embraced standards like CMMI and dramatically improved their software development performance, it has done very little to improve the quality and performance of IT support services.
The following Gartner study published in 2006 (figure 1) shows functional distribution of IT budget spent over a 5 year period. As can be seen by the chart, application development consumes an average of only 20% of the budget while the remaining budget is consumed providing IT support services.
Not only do IT support services consume most of the IT budget, they also require the most direct and continuous interaction with business customers. These factors suggest that we should have a separate methodology which directly addresses the management of IT services. A service management methodology and development methodology operate very well together, but we must know where one leaves off and the other begins. Both methodologies are important, but each is designed to accomplish different goals and measure different things.
Service management methodologies encompass a wide variety of processes and desired service outcomes, however, here we will focus on one very critical element of service management, the Service Level Agreement (SLA). The SLA is the glue that holds together the relationship between the IT service provider and the business customer. Ultimately all other service processes and outcomes support the customer SLA.
IT organizations provide a wide variety of support services to the business from infrastructure (networks and Help Desk) to business application software support.
As service providers IT organizations must demonstrate “value” to business customers. In this case, demonstrating value means delivering support services that meet or exceed the needs of the business at a cost that represents value. Service Level Agreements (SLA’s) help demonstrate value by clearly identifying the service responsibilities of the IT organization and performance expectations of the business customer.
Fundamentally the SLA is a contract between the IT service provider and the business customer receiving the service.
In order to demonstrate “value” the IT service provider must develop an SLA that clearly defines what support services are being delivered and the level of performance required by the business customer.
SLA’s are developed for specific IT organization and business customer combinations. Different combinations require different services and performance levels. We need to consider these combinations carefully when developing an SLA because they can significantly alter the scope and content. For example, an infrastructure network support SLA would be different from a software application support SLA. The basic structure of the SLA would be the same but specific services being provided and performance goals would be different.
One of the most difficult issues in developing an SLA is: What do I put in one? The following sample Service Level Agreement structure will provide a good starting point. When developing SLA’s it is easy to easy confuse the difference between the terms SLA, SLG and SIG. A definition which helped me is that an “SLA” is the overall service level agreement which not only describes the services being delivered but also contains Service Level Goals (SLG) and Service Improvement Goals (SIG) which represent service performance goals required by the business customer. Both SLG’s and SIG’s are discussed in greater detail within the following sample SLA structure.
Sample SLA (Service Level Agreement) Structure
Introduction – This section identifies the IT organization delivering the service, the business customer receiving the service, and the service relationship between them. An example would be: Infrastructure Group, providing network support for a shipping warehouse or Application Support Group providing support for the time-attendance system within the payroll department.
Description of Services – What services will be provided, what types of work will be performed, and the parameters of service delivery.
- Describe the types of service and work that are part of service delivery (Maintenance/Enhancements, Incident Repair, Technical Support
- Hours and days of support for different types and levels of service
- Service contact process and detailed contact information
Description of Responsibilities: This section describes who is responsible for what within the framework of services being delivered and received. Responsibilities can go two ways:
- Responsibilities of the IT service provider
- Responsibilities of the customer
- Responsibilities shared by both
In order to achieve service commitments defined within the SLA it is important to agree to the operational parameters which govern the service delivery environment. These operational parameters may affect service performance and therefore must be defined and monitored. If operational parameters move outside the control of the service provider or users of the service exceed the limits of their specified operational parameters, then the SLA may need to be renegotiated.
- Example: Maximum number of concurrent on-line users
- Example: Peak number of Transactions per hour
- Example: Maximum number of concurrent user extracts or ad hoc queries
Service Levels Goals (SLG’s)
Service Levels Goals represent the performance expectations of the customer for specific services being delivered. SLG’s are performance expectations for defined service measurements (metrics). These measurements determine if the service provider is meeting the basic service commitments. Depending on the services and metrics, different data are required in order to measure service performance.
- Example SLG: Metric: Equipment/Network Availability – SLG: 99% 24/7
- Example SLG: Metric: Critical incidents resolved SLG: within 2 hours
SLG’s are useless unless actual performance data are collected, measured and reported against service commitments stated in the Service Level Agreement.
Service Improvement Goals (SIG’s)
Service Improvement Goals (SIG’s) establish the required amount and rate of improvement for a specific SLG over time. An SIG requires that not only specific SLG performance data is captured but also that a performance trend is calculated over a specified period of time. This trend indicates the rate of improvement and if the improvement goal has been achieved.
Service Performance Incentives / Penalties
An SLA may contain a service performance incentives or penalty clauses. These may be written in such a way that provides financial incentives for exceeding service goals penalizes the service provider if service goals are not met.
Service Performance Reporting
Service reports and graphs are must be produced by service provider for the customer which communicates the comparison of actual service performance to service goals. The following (Figure 2) is an example which measures service level performance of an IT support team.
The above graph displays IT service performance as compared to all service level goal metrics for the IT support team. The graph shows whether the IT resources were either “Within or Outside” performance goal guidelines. This is a simple “Yes – No” measurement, either the service goals were achieved or they were not met.
Any SLA requires the signoff by the service provider and the customer. The SLA is a contract; therefore signatures by authorized representatives of the IT organization delivering the service and the business customer receiving the service are required.