When good IT contracts go bad
As an IT executive you will have a Service Level Agreement with your IT service provider. Well done. The bad news is that you’ve wasted your time, and often transferred risk back to yourself.
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 – to support the way they already operate. Do you think they won’t try as hard as they can when things go wrong? Another thought – if you want true 24/7 uptime, it’ll cost you a bomb. Your supplier will have to put in redundancy, deep monitoring systems, duplication of infrastructure, and constant management attention. They won’t do this for free – 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’s no such thing as perfect technology (or users, or processes – often the cause of the problem is in your organization).
Your SLA is nothing more than a description of what your service provider believes are achievable targets given the way they operate. They are merely managing your expectations for when they fail (and they will fail).
But what are your real expectations? They’re 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’s good business for them, given the SLA that governs their delivery.
A service provider will point to their green SLA dashboard and say they’re meeting your expectations. But are they meeting any of your real expectations? 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’t care about IT – they care about getting business done.
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. 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.
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 “demand-trigger” 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…), 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.
You need a partnership contract that assumes that business is volatile, but the relationship is constant.
Companies with existing SLA contracts need not fret too much either. Here, the concept of “backsourcing” comes in. Step one is to agree with your current supplier that the relationship is the important thing, and the SLA is unhelpful in moderating this relationship. Then develop a set of relationship metrics that suit both parties in a partnering context. Then agree to a flexible contract, where you formalise the relationship, and reconstruct the service requirements as variables dependent on demand conditions.
Real options valuation comes in useful here – it’s a simple concept that allows for an “invest to test” approach. Say the existing monitoring service is limited, and you want extensive monitoring. The invest to test approach agrees that the client will fund a pilot only, with the real option of stopping, further testing, changing direction, scaling, or postponing. The emphasis is on “real” – both parties agree that at the end of the pilot, the ball is in the client’s court. There’s no lock-in to the pilot – it’s not “project stage one” in a waterfall.
The bottom line here is this: SLAs waste your time, don’t guarantee good business outcomes, and drive the wrong behaviours in suppliers. Relationship based contracts that are flexible with regards to services, are responsive, agile, drive the right behaviours and ultimately match the services you receive to your changing business needs.
Author – Barbi Goldblatt – Regional Executive
