Abandoning service level agreements will not hinder the business, but free up valuable management time, says Colin Beveridge
We have so many acronyms in the IT industry that I’m sure we could drop quite a few without anybody mourning their loss.
But let’s not just mess around with some of the more obscure terms that clutter up our business vocabulary, let’s start with one of the really big acronyms that has outstayed its welcome: SLA.
Yes, I really do propose that we abolish both the acronym SLA and its expanded form, service level agreement.
I believe that these terms do more harm than good in the IT world and that they are particularly counter-productive in our efforts to foster meaningful relationships throughout our business value chains.
IT very often has to play pig in the middle between unhappy business customers and perplexed service providers brandishing their SLA reports that clearly demonstrate that they are delivering their promises.
Why would anybody in their right mind expect our business customers to rejoice over the fact that an e-mail server actually managed to stay up for more than 98% of the time in the previous month?
Unfortunately, though, too many IT departments still persist with such reporting, in the misguided belief that their SLA statistics demonstrate real value added to the success of the organisation.
Sorry guys, but this obsession with outdated SLAs is tantamount to a building facilities manager expecting kudos for the routine availability of heat, light and water.
But it’s not just availability SLAs with which I have a beef. I don’t like many of our help desk SLAs either, particularly where the service agreements encourage premature closure of service calls, in the hope of improving performance statistics. We must remember that people will always “play the system” wherever there is scope for exploitation.
I suppose the bottom line with my arguments against SLAs is that they do not usually address the primary attributes of service in terms of integrity, quality and value for money. Too many of our SLA measures are made against performance criteria that our customers either take for granted, or do not care about.
For example, I recently had to remediate a relationship where the finance director was increasingly apoplectic every month because the corporate accounting system had become virtually unusable during the month-end period, due to a significantly increased workload on the network and distributed finance servers.
Her concerns about delays to the group’s routine reporting cycle were seriously misaligned with the service provider’s perspective, which was acutely focused on an availability SLA that had not been breached for donkey’s years.
Nevertheless the availability SLA was worthless because even though the system was available as specified, its performance was so degraded as to make it unusable at the busiest time of the month.
What the finance director really needed in this situation was a straightforward guarantee that the finance systems would always cope with the peak demand from its customers.
And we should be able to give such guarantees to our customers, if we took more trouble to establish meaningful relationships between systems and the quality of service delivered.
To do this I strongly believe that we will not only need to abandon our much-prized dependence on historical SLAs but also to adopt quite a different approach to IT service management, a new approach that will also need some quite different tools and metrics.
And these tools and metrics will have to give us sufficiently dynamic information so that we can take action in real time, not just argue our case some weeks, or months later.
This won’t happen overnight, I know. But we can make a good start now by immediately dumping as many SLAs as possible, or at least stop reporting them, freeing up valuable management time to concentrate on the real issues of service integrity, quality and customer value for money.
Colin Beveridge is an independent consultant and leading commentator on technology management issues. He can be contacted at email@example.com