Five Best Practices for Creating SLAs in an ITSM Environment

According to the Information Technology Infrastructure Library v3 (ITIL v3), a Service Level Agreement (SLA) is “An Agreement between an IT Service Provider and a Customer. The SLA describes the IT Service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the Customer. A single SLA may cover multiple IT Services or multiple Customers.”

Simply put, an SLA defines what both the IT service provider and the customer should expect when contracting for a service.

In the ITIL service lifecycle described in our simple primer on IT Service Management (ITSM) and ITIL, SLAs are defined and modified in the Service Design and Continual Service Improvement core areas. This means that SLAs for IT services should be created alongside any specifications for new and updated services. Whenever an IT service is designed or changed, its accompanying SLA should also be reviewed and modified to make sure it is fair, enforceable, and realistic.

Given this, here are five best practices for creating and fulfilling IT service SLAs in an ITSM environment.

#1: Separate SLAs should be created for each IT service that needs measurement

SLAs are a collection of promises made to the customer. Avoid creating a single SLA for your entire service catalogue. Rather than defining that all IT service requests will be fulfilled in five hours for example, create separate SLAs for each IT service you want to track. Some examples might include:

• A new user will be created within one day of receiving an approved new user request form
• User terminations will be processed at the end of the user’s last day for friendly departures, or immediately for unfriendly departures
• New phones will be ordered and delivered within one week of request

Each IT service will have its own lead time and approval schedule, and must be completed accordingly.

#2: An SLA must be quantitative, well researched, and authoritative

An SLA measurement should neither be a wild guess nor a truce in a battle with your customer. SLAs should be based on quantitative (or real) data. An SLA promise should reflect knowledge gained on what it takes to deliver the new or improved service based on actual prior experience (yours, your customers, or industry standards), along with testing and prototyping the service during the design and continual review phases. An SLA for how long it should take to install software for example, should be an actual, achievable number that the IT Service Provider can be held accountable for and has the capacity to reach.

 

#3: SLAs must be measurable

Your ITSM service desk must be capable of gathering and presenting the necessary metrics to determine whether an SLA has been accomplished. SLAs must represent SMART goals (Specific, Measurable, Achievable, Relevant, and Timely), and each individual SLA must possess the following characteristics.

• Specific – An SLA must be specific and detailed enough to define expectations for service delivery.
• Measurable – There must be a way to track actual performance against the promised SLA. Many service management platforms including BMC’s Remedy 9 contain capabilities for recording the SLA that an IT service will be measured against plus the actual time or other service measurement that will be recorded. It’s difficult to accumulate and prove SLA performance if your basic management tools don’t include SLA targets and time worked in delivering service catalogue items.
• Achievable – The SLA must be realistic and able to be met. Unrealistic goals can demotivate your service delivery team.
• Relevant – The SLA must be directly related to the IT service being delivered and it must be relevant to evaluating performance against that goal.
• Timely – The SLA must contain a time frame against which the service will be delivered

An IT service provider must not only be able to gather data about SLA performance, they must also be able to report on that performance. Make sure your service management software is up to both tasks.

#4: SLAs require periodic review and adjustment, as part of the ITIL Continual Service improvement core area

An SLA should be reviewed and updated whenever there are any proposed or promised changes for that service, under your Continual Service Improvement process. Be sure to adjust the SLA for any change that affects service hours, availability, uptime, completion, or response time. It’s tragic when because of IT service improvement, a provider can no longer meet their service level targets and it either loses a customer or faces SLA non-compliance penalties.

#5: SLAs should account for usual and unusual exceptions

It’s as important to define where the SLA doesn’t apply as where it does apply. Your SLA should define any usual and unusual situations that will hold up IT service processing. Some SLA exception examples might include:

• All orders will be released within one hour of receipt, except for Sundays between 1:00 AM and 4:00 AM when system maintenance is occurring.
• New computers will be configured and delivered within five business days, except for weeks where a holiday occurs. Additional days will be needed when a holiday falls within the delivery period.
• New users will be added to the system within one day of a completed new user form, provided management has approved adding the user. It will not be considered a service level miss if a new user request has been received but management is slow in approving the new user.
• SLA targets will be temporarily waived in the event of a local or regional disaster affecting service, including but not limited to fires, floods, earthquakes, extended electrical or network outages, etc.

IMHO, these are five of the best practices to follow when creating SLAs for IT service delivery. To find out more about service level management in an ITIL environment, check out BMC’s guides on ITIL Service Design Processes and ITIL Continual Service Improvement.