02 December 2012

Ban the SLA

Business people just don’t get it. 

This strange stuff that we IT folk force-feed down their throats. 

Like SLAs. 

All very high-ceremony, with formal procedures for this and that, most of which seems inside-out if not inside-in. Subtle differences between incidents, problems and service requests. 

"I REALLY DON’T CARE – JUST HELP ME GET BACK TO WORK INSTEAD OF ME WASTING MY LIFE TRYING TO WORK OUT HOW TO AVOID DEALING WITH YOU."

They only play along with this SLA nonsense because they know that it’ll cost them even more time and energy to get us to change our ways. So then we get into discussions about response times and resolution times with us saying
 “No we can’t possibly guarantee a resolution time because one of the widgets is out of support”.
And they say “Yes but all I want to know is what kind of a delay will I have when there’s an outage”
… “Oh, we couldn’t possibly say – it depends on so many variables” …
 “But you’ve been doing this for years, surely you know what to expect?”

And so it continues, ending up with both sides adding preconditions and exceptions and penalties. This reminds me of the build-up of nuclear weapons half way through the previous century. And the Ban the Bomb movement and nuclear disarmament. 

I believe that the time has come for the Ban the SLA movement leading to an Anti-Ballistic SLA Treaty and a Strategic SLA Limitation Treaty (SALT), leading in turn to Service Level Agreement Termination (SLAT) and SLA disarmament. 

An interesting alternative to SLA’s is the Service Charter. Not the same Service Charter as defined by ITIL 2011 as “A document that contains details of a new or changed service” but a high-level document that sets intentions and general expectations. Deakin University in Australia has a good example and, strangely enough, most service charters seem to be used down-under. It’s only fair to state that that a service charter is not detailed enough replace the contract between business and IT, but it is certainly a more fitting instrument to lull them into a false sense of security before launching our all-out service level attack.  

Note: James Finister prompted me to write this for his blog.

No comments:

Post a Comment