As an IT executive you will have a Service Level Agreement with your IT service provider. Well done. The bad news is that you\u2019ve wasted your time, and often transferred risk back to yourself.<\/p>\n\n\n\n
Think about it. Do you want uptime, resolution times, and to penalise the supplier when they get it wrong? Or do you want problems to be resolved as quickly as possible, so that you can get back to work? SLAs are always written to favour the supplier \u2013 to support the way they already operate. Do you think they won\u2019t try as hard as they can when things go wrong? Another thought \u2013 if you want true 24\/7 uptime, it\u2019ll cost you a bomb. Your supplier will have to put in redundancy, deep monitoring systems, duplication of infrastructure, and constant management attention. They won\u2019t do this for free \u2013 they will argue that because your requirement is unique, you should bear the cost of meeting that requirement. And still things will fail, because there\u2019s no such thing as perfect technology (or users, or processes \u2013 often the cause of the problem is in your organization).<\/p>\n\n\n\n
Your SLA is nothing more than a description of what your service provider believes are achievable targets given the way they operate<\/em><\/strong>. They are merely managing your expectations for when they fail (and they will fail).<\/p>\n\n\n\n But what are your real expectations? They\u2019re not about technology for sure. They are probably around issues such as being responsive to business needs, being agile, achieving business results, having an acceptable IT service, meeting customer needs and being a trusted partner to your business. An SLA drives the opposite behaviour in your service provider. It drives them to provide the minimum service at a minimum cost to themselves. That\u2019s good business for them, given the SLA that governs their delivery.<\/p>\n\n\n\n A service provider will point to their green SLA dashboard and say they\u2019re meeting your expectations. But are they meeting any of your real expectations?<\/em><\/strong> Even the expectation of an acceptable IT service is often not met by an SLA. How often have you been presented with a green SLA dashboard but have frustrated users? Because users don\u2019t care about IT \u2013 they care about getting business done.<\/p>\n\n\n\n If an SLA drives supplier behaviour, then what will drive the behaviours that you actually want? You need a partnership agreement with your supplier which acknowledges that your business changes as do your expectations.<\/em><\/strong> Partnership is the important word here. An SLA is usually a once-off supplier agreement, while a partnership is a continual and evolving collaboration to provide services that meet your expectations.<\/p>\n\n\n\n There is a move towards flexible contracting in IT service contracts. A flexible contract has, at its core, clauses that cover the relationship or partnership. It assumes that business is volatile, but the relationship is constant. It has variable clauses (usually in an addendum) which outline \u201cdemand-trigger\u201d conditions: Those conditions which will trigger a cooperative effort in the partnership to meet the service requirements. These conditions are usually based on response triggers (our competitors have done xxx, we must respond with yyy), risk conditions (the price of fuel is making our logistics uneconomic, we must\u2026), or growth conditions (including shrink or decrease conditions). If flexible contracts look like more work than SLA contracts, perhaps you should look at the wasted time on SLAs, versus the productive time in getting the services you need given your changing conditions.<\/p>\n\n