SLA & Scheduling Objectives in Project Management

Let’s kick off this article with a reminder that ITIL divides Priorities into two work groups: 

• Incidents  

• Service Requests 

We’ll follow this separation by saying that SLA’s are to Incidents what Scheduling Objectives are to Service Requests.   If you think about it, SLA’s measure response, resolution planning, and remediation -which are applicable measurements to Incidents, but not applicable to Service Requests. However, there is a sister concept with a Service Request that asks: “How long will the Customer wait for engagement for a priority level of a Scheduled Event?”   

How SLA’s Relate to Incidents for an IT Managed Service Provider (MSP) 

There are two ways to look at the value of an SLA:  1) A measure of IT Support performance that can be benchmarked and used as a basis for continuous quality improvement. Tip: for more on this term, research Total Quality Management (TQM) by W. Edwards Deming. Here we are just monitoring, tracking, adjusting and letting the performance float to whatever level the IT Support Team can deliver.  2) To drive Automation and workforce performance to meet a predefined goal. The Automation is primarily a communication system that is used to engage management when needed to meet SLA goals.   Notifications of this system include:   

• Critical Service Request has been received  

• Service Request due within X of hours or minutes  

• Service Request is in jeopardy of missing an SLA goal, etc.  

The best way to apply SLA’s is to use them as a benchmark for TQM.  What’s your take on this? Do you agree? Share your thoughts in the reply section below.  Most of the time, we think of Service Level Agreements as being tied to the Agreements signed with the Customer - and they are, in many ways (Priorities, Response Times, who goes first, etc.).  But what’s important is that they are also tied to non-Agreements not signed with the Customer. As mentioned, one of the best practices for Incident Service Requests is to use the Next SLA Due Date to prioritize which Ticket needs to be worked on next.   This is great for Contractual Customers, but what if they do not have a Contract with you? I put forth the argument that if they do not have a signed agreement with you, then they have an unsigned agreement (T&M) and a non-contract SLA is applied to the Ticket.  

 2 Ways the Next SLA Due Date Can Help 

1) We can now use the Next SLA Due Date to prioritize all Tickets in the Queues – both Contract and Non-Contract Customers.  2) Non-Contract SLA’s drive upsell opportunities. My recommendation is that the SLA for non-contract service requests be set at 4X Contract SLA’s.  We have set it at 2X, but non-Contract Customers seem to be okay with this. At 4X, they will ask to be expedited/escalated, to which the response is, “Sorry, we have Contractual Obligations that need to be met first. We will get to your request with our best effort as soon as our Contractual Customers are taken care of.”   Their response most the time will be “How do I get one of these Contractual Obligations?”…At which time the CSR or Tech sends them to the Account Manager.  

Measures of SLA’s at the IT MSP 

As we can see, SLA’s are used to measure or drive IT Support service to the Customer performance. As long as the expected First Response, Resolution Plan, and Remediation due dates/times are the same across different Service Levels, then the same SLA can be used.  For example, if Platinum Level includes 7/24/365 and the rest of the levels (Gold and Silver) are Business Hours, then three SLA’s can be set up and used.   The Three SLA’s are referred to as: 

1. 7/24/365  

1. Basic SLA  

1. Non-Contract SLA 

While all three metrics are set up & used across all Incident Priorities, all levels of service, and used for Contract and Non-Contract agreements, they are not all reported to the Customer.  The only part of SLA performance that the MSP has complete control over is the First Response. The others are impacted by Vendors, Weather, and the Customer themselves.  This is not to say the MSP is completely off the hook. They are still responsible for Staffing Levels, Skill Levels, Tools, and processes.  Therefore, only the First Response should be discussed with the Customer and reduced to writing in the Agreements. However, the other metrics are critical to be benchmarked, tracked, and managed for the Technicians so that Customer satisfaction can be maximized.   ** W. Edwards Deming’s 14 points for Totals Quality Management