There is even more to SLAs than meets the eye…
Following from my article ‘There is more to an SLA than meets the eye’, Faisal Zahir posted a very interesting question that deserves exploring at more length than a discussion thread. Accordingly I decided to make it into a separate column.
Faisal Zahir wrote:
“Excellent article Ernst. Your third point ‘the customer has to be happy if the SLAs are achieved’ is extremely important, as we see many cases where all SLAs are green but customer is still not happy… I would also like to know your thoughts on how SLA should be designed in an environment where the service provider is not in control of everything required to ensure meeting the SLA. Should we have no SLAs at all or is there an alternative.”
It seems to me there are three important questions here.
1. What do we do when the SLAs are all green but the customer is not happy?
These can be difficult to deal with and can have various causes.
Most obviously, the SLA might not measure what the business really needs. Especially for a first-time outsourcing customer, these requirements are not easy to set. Also they won’t stand still, so even if today’s SLA is right it might well not be right tomorrow.
At the moment I’m having a discussion with a client who runs a market-facing business unit that needs higher service levels than contracted for, in order to be competitive and to get the benefit of a new application. It seems to me that the main thing in such situations is to accept unemotionally that the company has contracted for service level x and now it needs service level y, that we shouldn’t be surprised that requirements change over the life of a contract, and must establish what service level y would cost. Or at any rate have a grown-up conversation between the parties to understand what the price/quality trade-off looks like and whether we want to move to another point along that trade-off.
Another answer might be found in how failure is dealt with in both the business and IT domains. Where a higher service level isn’t achievable it might be possible to make the result of failure more bearable.
2. Should we have no SLAs?
It is hard to imagine a situation where we wouldn’t want SLAs. Consider a few points of view:
SLAs set clear expectations that allows a positive relationship between the parties. As a supplier, I want to be able to say to the customer “I know I’m only contracted to provide 99 per cent but last month we managed 99.4 per cent”. Without the SLA I just get beaten up for not being 100 per cent.
Still as a supplier, I want my internal customer (the CIO, say) to tell the business users “the service provider isn’t perfect but all their service levels are green so we’re getting the service we contracted for, or better. If you want better, we’ll have to pay extra”.
As a customer, I want the service provider to have every incentive to deliver at least the contracted service level. If not, they pay a fine (service credit) or eventually there may be the option to terminate for cause. How else do I give them an incentive to give a good service or get rid of them in case of persistent failure?
Still as a customer, I want the internal discussion inside the service provider organisation to be along the lines of “yes we have cost challenges but we can’t raid the XYZ account because then we will miss our SLAs and have to pay service credits”.
These are all important considerations.
3. How do we structure SLAs where the service provider isn’t in control of everything required to ensure meeting the SLA?
Let’s distinguish between two cases.
Case 1 is where the service provider is responsible for outcomes they can’t control technically. For instance, to provide service availability might require electrical power or data communications which the service provider acquires from its subcontractors. In this case the customer must insist on availability SLAs and it is for the service provider to choose subcontractors who can provide the necessary quality of service, or to arrange for contingencies.
Case 2 is where the service provider isn’t contractually responsible for the service to which the SLA applies. This is a surprisingly frequent request by customers. For example, a customer might contract separately with three parties and expect one of them to act as integrator and assume responsibility for end-to-end delivery. A sensible service provider can then express a willingness to manage the others for the customer but without accepting responsibility for their work, or offer to act as prime contractor for a different price that reflects the added responsibility and risk This debate may get nowhere if the customer doesn’t want to pay extra and the service provider doesn’t want to take on the integration risk for free. Of course the customer might be naïve but that isn’t against the law; also he might consciously be trying this as a negotiating device by asking for more work for the same price.
There are many possible outcomes depending inter alia on the overall relationships, but one is for a contract to be signed with no agreed clear SLA because the customer wants the wide scope and the service provider wants a narrow one. Or if there is an SLA then it might be unclear or there might be contradictory wording elsewhere, so each party has some words to point to.
In some ways it might be better for all concerned to walk away from such a deal, but we don’t always have that choice. Dare I say it, this might also happen when the sales pressure inside the service provider is stronger than the delivery caution. All you can do is to hope that the technical delivery works well because if it doesn’t, the commercials are going to make for a messy argument.
Back to the question then: the problem is the lack of agreement on the scope of work, and then fudging this disagreement. The SLA reflects this fudge. The fix is to have a clear agreement on the responsibility of each party, because truth will out and so will fudges. If you are very clear about the scope, I don’t see why there should be a problem with writing meaningful SLAs.
As always there are many right answers and I hope this is one.