Home » Currently Reading:

Structuring SLA’s for IT Support

BobAndersonPicFmComputerWorld

By: Bob Anderson

Director Process Development and Quality Assurance

Computer Aid, Inc.

bob_anderson@compaid.com

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.

Gartner_Graph

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

Operational Parameters

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.

SLA Graph

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.

SLA Signoff

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.

Our Sponsors

IT Support Services Comments

  • Network Management Service: IT is connected to business. Good IT services help in business. The objectives of IT must be framed by aligning it with business requirement....
  • IT Support Services: The post is really good and is very descriptive. The discussion provided is very clear. Thanks for sharing this post regarding the IT services provided....
  • Connor: Absolutely agree with alosmt everything you wrote. And about time there was a voice of dissent as I’ve been alone in the wilderness for too long! ITIL v2 was pretty good as a framework but then ...
  • pudin: Spot on. ITIL is a load of old Tripe. ITIL is a fwremaork but it is common sense. We have stopped all ITIL training.Peer to Peer learning and focus groups have delivered better and more measurable ...
  • Woo: Stopping in for a quick hi to Mary and Lesli. Great intirveew! I didn't even know we're supposed to count our WIPs. Guess I need to pull out the ol' file.Kudos to the parents/grandparen...

ITIL V3 Application Support Q & A

If you have any question on the blog content or have some specific question on how ITSM & ITIL can dramatically improve performance and reduce the cost of your Application Support service "Ask Bob"
Question :
Answer :
Gunter, there are many possible SLA components and metrics that can be defined for any application software support. First I would recommend that you read this article which I had published in Computer World on "How to create Meaningful IT Support SLA's"  use this link...
Question :
Answer :
Daniel, from a certain point of view you are correct. CMMI- DEV deals primarily with software development best practices, the old CMM Level-5 dealt a great deal with defects. However, as you know the folks who developed the original CMM  were not really initially inter...
Question :
Answer :
Amiet, I would put it under the "Incident" process and track dates, number of occurrences, how much lost time, cause (who did it). You will need data for management if the practice has to stop. If you want to be "proactive" in stopping this practice" you must capture bu...
Question :
Answer :
Mark, it is doubtful that you can fix the problem, it is mainly a management issue. The best you can do is to gather statistics on the backlog of enhancements, the number and severity of incidents, and how many technical support calls from users you get and the average...
Question :
Answer :
Amit, first of all why is the customer powering down the equipment? This should be brought to the attention of management and a very strong note sent to whoever is doing this.  If they are doing it on their own without any instruction to do so and it affects other user...