To draft service levels and manage relationships well, you merely have to remember that they need to be SMART (as made popular by Peter Drucker): Specific, Measurable, Attainable, Relevant, Time-Bound, blending the rationality and romanticism as we go. Recall from the first four parts of this series that we were discussing Strategic Supplier Management. In this fifth of five-part series, we’re going to put it all together.
Now that you’ve considered all five requirements, you should have one or more appropriate service levels in mind. But if you’ve never drafted a service level before or don’t have a lot of experience in writing them, you might need some help getting started. Therefore, here are some starting points for a few key service level metrics. These are the ones common for software-related contracts – so they’re not going to be universally applicable to everyone or to all situations. But they might give you a jumping off point for the creation of your own.
Software-related services are typically measured by two major factors: Problem Response (how quickly the supplier responds to a call for help) and Problem Resolution (how quickly the supplier solves the problem). As two measures of time, they’re similar, but these are two independent measures – a supplier can do well with one and poorly with the other. Additionally, embedded in both of these metrics is a key definition – the concept of Severity. So we actually have to start with some definitions and work forward.
Not all problems are created equal. Severity is the disambiguation of a particular issues’ importance. You should create at least three Severity levels, perhaps four, but never more. Four levels offer enough distinction between each Severity level without becoming so nuanced as to be irrelevant. Sev1 Problems are usually any problem resulting in a full or partial production stoppage or data inaccuracy. Sev2 Problems are a significant production inhibitor. Sev3 Problems are those where we can do our work, but only through manual intervention that requires significant production or performance inefficiency, or where reporting functions are unavailable. Finally, Sev4 Problems are any condition in/of the software other than those defined as Sev1-3, which affects the service or operation of our systems or network, but does not render such system or network unusable or inoperable.
The net result is that Sev1′s are “the sky is falling” moments; Sev2′s are “holy cow”; Sev3′s are “we’re pulling an all-nighter” and Sev4′s are “I don’t like having to do something in this really wacked-out way because the software doesn’t work to the manual’s spec”. Of course, you can redefine Severity Levels any way that you wish, but the general formula should be followed (because these are almost industry standard). As you’ll see in a moment, the distinction between each level is also important in terms of how it impacts your metrics. Additionally, for those who are used to five levels, the “missing” 5th severity level is one we simply don’t include anymore – the “user interface” issue – the color palate that makes things hard to read, the minor nit that isn’t inhibiting in any way, it’s just an annoyance.
Now that you have the Severity Levels defined, you can return to the creation of metrics for Response and Resolution time. Remember that Response Time is how quickly the supplier is going to answer a call for help. Thinking logically then, the higher the Severity Level, the quicker the supplier should respond because the more damage delay in response would cause. Our standard starts with 2-hour response time for Sev1, 4 hours for Sev2, 8 hours for Sev3 and 12 hours for Sev4. Remember, this is just response time – the time it should take the supplier to give you a PLAN for a resolution, not to actually solve the problem.
With Resolution Time, on the other hand, we again measure time, but are also measuring completeness, as Resolutions are dependent upon the problem being fully solved (hence the definition of the word “resolution”). For Sev1 Problems, we need immediate assistance, tempered with a little understanding of how software development works. So we ask for 100% of Problem(s) resolved in 24 hours. We follow an almost identical geometric path as with the Response Times. Sev2′s should be resolved in 48 hours, Sev3′s in 72 hours and Sev4′s in 96 hours.
Seems pretty simple, actually. And, in many cases, it can be. But again, if we didn’t have a fairly thorough understanding of the software development, testing/QA and bug identification/repair process, we might be tempted to ask for unreasonable metrics, or alternatively, be willing to agree to extremely long times as well. Again, the moral of the story is to know what you want to measure and why and go from there.
But what happens in the event that the Service Levels aren’t met (they’re “blown”)?
Remember why we sought Service Levels in the first place – usually because we really just want what you’ve been promised in terms of service or performance. In this case, remedies for blown Service Levels should be two-fold: 1) to get service restored as quickly as possible, and 2) to recompense for any damages caused as a result of the blown service level. So you’ve probably even drafted the Service Level metrics so as to put a lot of importance on fewer outages or less downtime – with significant financial penalties. But you don’t really want the money, you want great service. The net result is that in the event of a blown Service Level, you probably won’t enforce the financial penalty… it’s more bark than bite. But you are a stickler for responsiveness and attentiveness, and you will enforce the remedies if you feel that not only have the Service Levels been blown, but that you’re getting ignored, too. This is justifiable.
But maybe you’ve got a little more jaded view and you already know that you’re not going to get exactly what was promised. You drafted the Service Levels with really tight controls – trying to count every little thing (without regard to what’s really important) in the particular deal. You instead feel that software or services are exact sciences and that if the supplier is silly enough to make a promise, you should get everything you’re “entitled” to. The result is that at the first hint of a blown Service Level, you’re on the phone with the supplier asking for service credits (never mind restoration of service).
Personally, we hope you’re in the first group of folks and not the second. Software and Services, by their nature, are going to have hiccups. This is just how it goes. Even older, established products can have difficulties (environments are constantly changing). So instead of trying to beat the supplier with your contract, you use the contract strategically to make sure that you’re getting what is really important to the deal … and not some sort of small financial benefit for each blown level.
However, there are times where it is absolutely justifiable to use the contract as a sword and a shield. One of these cases is what’s known as “death by ducks” – the situation where you have many small Service Level issues. None of them, on their own, would be worth enforcing as a true blown event. But together, you get pecked to death by the small things because they cumulatively add up to a significant performance issue. Here, you should have anticipated this issue and have a small extra section in your Service Level language detailing the remedies available in the event of x number of small issues that add up to a certain Severity Level. You can even define it as a certain number of Sev3′s = a Sev2. And a certain number of Sev2′s = a Sev1.
At the end of the day, the SMARTest service levels will serve both you and your IT supplier to develop a healthy, responsible, sustainable relationship – exactly the relationship that both of you intended to create at the outset.
NET(net)’s Website/Blogs/Articles and other content is subject to NET(net)’s legal terms offered for general information purposes only, and while NET(net) may offer views and opinions regarding the subject matter, such views and opinions are not intended to malign or disparage any other company or other individual or group.
For more information on how NET(net)’s Strategic Supplier Managed service can make your deals SMART, visit Managed Services
