I asked Mark to expand on his thinking for this blog, and this is his response. Before anyone posts a particularly inflammatory response I should say there seemed to be some sort of eventual consensus at the conference that the slogan has to be seen in conjunction with the concept of a Service Charter, as Mark suggests.
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.
Posts
Perhaps some of the issue comes from believing that an SLA is a single kind of document, with a structure, scope and content determined in some remote place. What sensible practice should convey is that you develop teh document you need - and no more than you need. Organisations that will not get benefits from a detailed and precise pseudo-contractual document between parties (SLA?) shouldn't spend time and money creating one. Those who will get benefits from a looser statement of intent and expectation (charter?) should do that - and do it quickly.
ReplyDeleteAs in all things It and SM, the answer is it depends - but match it to customer needs (I think I've seen that written down before a few times but we should always come back to it.)
I must admit my thinking on this remains heavily influenced by a discussion with Bertal Aukema when we were at Quint. The conclusion was that whilst SLAs should work in theory (and you might want to discuss what it means for an SLA to "work") we had never seen one thta worked in practice, and that suggested there might be a systematic flaw in the concept.
ReplyDeleteThese days my Service Integration experience suggests the prroblem is that the individual components of a service thatw e tend to define in an SLA don't add up to the customer's perception of the service. The sum of the parts doesn't add up to the whole. That's why we frequently get the situation where every KPI is beign achieved but the business remainds deeply dissatisfied.
Having said that there are still some truly awful SLAs out there which obscure the picture.
Agasin back in my Quint days we liked the idea of defining Service Objectives to try and capture the aspirational qualitative nature of the service required and that roughly equates, i think, to the concept of service charter as outlined here.
Delving back into my memory I thinka t that time we talked about the service charter as a document that covered the general nature of all IT services across the customer base, such as making decisons based on business priority,with the SLAs then being very service/customer specific.
Once again we shoot the message.
ReplyDeleteITSM documents reality and attempts to put some structure around reality so that we can systematically try to improve reality. That is a definition of ITSM, not an observation.
There is an agreement between the provider and supplier of a service. Always. it includes some expectation of service levels. Always.
it may be implicit or explicit, it may be formal or informal, but in every case of a service being proviced there IS a service level agreement.
You can't ban SLAs any more than you can ban gravity.
You can argue the format, the content, the intent, the mechanism etc etc but there is always an SLA.
A huge formal document with detailed SLTs is no more the only type of SLA than a Bugatti Veyron is the only type of car.
Coming up with endless new terms is not helpful. Much more useful would be to discuss how to improve SLAs
Rob,
DeleteSadly we come back to the laboratory of the real world. Creating SLAs sets up expectations of service improvement that the average IT department isn't able to to live up to. I'll accept that an SLA is usually better than nothing, but it doesn't replace the need for intelligence in monitoring and delivering services. And whilst there might be lots of theoretically possible wonderful logical equivalents of the SLA the danger remains that both the SLA and the SerCat have turned into the fetish objects of a cargo cult.
Are we really just talking about replacing the typical SLA with a new type of SLA? Possibly, but if it gets rid of some of the awful template documents that are out there than that can only be a good thing.
If I have a real gripe about SLAs it is that more often than not they aren't actually an agreement, as evidenced by how little actual negotiation goes on around them. There are good reasons why they can't be, especially when created retrospectively and applied to systems running on an under invested. infrastructure.
I agree there's always an expectations around service levels, regardless of documented agreements or not. I think the problem with formal SLAs is that they tend to force IT-centric terminology and thinking on customers who really just want to do their business, and not have to worry about 'things IT'.
ReplyDeleteI do prefer SLA that are more Service Level Objective slanted, and there's really no substitute for good relationships with customers. In the end, it's all about value to the business/
I considered calling the blog 'Ban the unilaterally imposed SLA that reflects the unhealthily asymmetric relationship between business and IT' but I thought it wasn't catchy enough so I dropped the qualification.
ReplyDeleteCouple of points to take the discussion towards guidance:
1. One size doesn't fit all
2. Package the content in language that reflects business needs
Re 1. As always, the Skep's touched on a relevant topic. Expanding his car analogy, if you look at information systems as if they were forms of transport (train, bus, car, scooter), you'd agree with me that their different functions justify different SLAs. In terms of both utility and warranty. ijm referred to this as well.
Re 2. Greg pinpointed one of the SLA sins: IT-centric terminology. I'm struggling with this as much as the next man, but my best effort at formulating categories of IT services that appeal to business managers in the sense that they fulfill a business need:
- Build or acquire, and then deploy functionality that supports the business processes
- Ensure that the functionality is operational and fit for use
- Provide operational services such as providing a new user with access to the information systems, running an IT function that is too technical for a user, e.g. a batch run, and supporting the users when queries and problems occur
- Change the functionality when business processes change and to improve how current business processes are supported
- Advise about the consequences of proposed changes and which changes should be considered, and advise about longer-term choices, such as adoption of social media technology and when to replace an application
- Decommission the functionality
Even if you only rearrange the content of a SLA into these categories, I'm convinced that business people will have a better understanding of why they should be buying the services. I've developed this a bit on my blog http://smalleysoneliners.blogspot.nl/2012/12/service-catalogues-business-perspective.html and in a 'Service catalogues from a business perspective' paper that I haven't published yet but will be pleased to send to anybody who's interested.
Referring to another of Greg's comments that puts the discussion into proportion, most of the above is about about the business-IT transaction, while the more challenging part is the relationship. And this is why the service charter appeals to me, because it addresses intentions.
I'm sure that the last word hasn't been said...
I agree with Skep’. Continuing the gravity analogy… The thing that you have to decide is whether you make the SLA explicit and if so are Newton’s laws sufficient or are you working near light speed so need to invoke Einstein’s theory as well.
ReplyDeleteRemember this. No IT budget allows for a 'perfect' service. Sooner or later someone will have to make a choice between paying for training on this rather than that, or stopping a support contract on this rather than that etc.
Ask yourself this, can the business handle the truth?
If you start exposing difficult decisions to the business (which service target do you need on which service and which trade-offs do you want make), they will start to wonder why they are paying you to make these difficult decisions for them. In the end they will probably find someone else who doesn't bother them with such dilemmas. ;-)
This comment has been removed by the author.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteIt struck me today during a conversation with a client that service documents have to fit in their context, whether that context is right or not. The issue for me with SLAs is that the context in which they are most needed is not one conducive to writing good SLAs, and when the context is good the need for an SLA is much diminished
ReplyDelete