According to Wikipedia, an SLA is:
“A service-level agreement is a negotiated agreement between two parties, where one is the customer and the other is the service provider. This can be a legally binding formal or an informal “contract” (for example, internal department relationships).“.
SLAs is a hot item in IT, and is given much weight in the organizational framework called ITIL.
Almost all IT directors I talk to rely heavily on SLAs or blame the lack of proper SLAs for lack of success.
But seriously, do you have an SLA with Google? With Facebook, Twitter or the scores of Internet services that you use personally? No – and if you are unhappy, you simply find another solution or service provider.
An IT service provider would be wise to simply scrap the SLA or any contract that seeks to bind the customer. Instead, let the customer be free to choose and move to another vendor if they feel like it. In that way, the service provider will have to be constantly performing better than the competition. And that is the best solution to keep the customers.
Instead of locking the customer with contracts, service the customer like no one else.
No contracts, no lock-in and you have no choice but to become and be the best.
Without even intellectual property protection, you would have to rely on pure and excellent service to retain your customers.
Customer lock-in mechanisms makes for laziness, dwindling creativity and thus ironically opens the door to better service providers.
SLAs are only warranted where the customer are not free to choose another provider, such as when the business strategy dictates the business units to only use the internal IT department.
14 thoughts on “Scrap the SLA (Service Level Agreement)”
Interesting point Geir. Whenever my business has done business with a Scn business in past.. ..the SLA has always come back to bite me. They don’t deliver and just say “I understand”
As Bill Mayer says….”new rule”…I don’t do biz with Scn anymore
I have always worked this way in business and have enjoyed friendly relations and remunerative success doing so.
Customers come and go and I thank them kindly and eventually I see them again because they circle back. I deliberately feel no ill will for their having left and when they show up again I simply say, “Good to hear from you. How can I help?” And I never ever mention to them their having been gone nor passively-aggressively attempt to penalize them for their having left for another vendor.
I truly do this for my own sanity but the ramification is a large database of current, -ex, and soon to be again current customers.
Great post Geir. I just came out of last week meeting with our internal IT Advisory dept. who is tasked by the board to evaluate our internal IT delivery and make recommendations to areas of improvement. In a very predictable way, their first move was to request documentation on everything among others our SLA against our Service Catalouge. I had hopes that this initiative would bring us something I could use to make a difference, create an agile and inovative IT service delivery that would not only support (because we do that today) but actually challenge the way we do our business, how we interact and value our customers, highlight and drive business efficiency and change in all BU’s, grow our market share and optimise our margins (for starters :-)). All this by using IT as a strategic tool, challenge the business model and at the same time deliver secure, stable and efficient IT Services.
But alas – Instead I now risk spending all my time reporting on statistic, relaying metrics on past performance and explaining to the business why it is a bad idea to consume all my resouces on lifting our uptime and performance from 98.8 to 99.1% of a metric no one cares about anyway.
It all went pear shaped when the PM opened the meeting by stating that one of the objectives must be for IT “to be able to defend its value” so having written and agreed (signed) SLA metrics against the SC is “a really good idea”. So in a very predictable way, I exploded 3 minutes into the meeting (it was that or to fall asleep), but realised 30 sec into my tantrum that I was coming over as I did not support the idea of measuring IT performance or having clear and well defined deliveries. As an afterthought I realised that we where having two totally different discussions and that I should have done a reality check before diving in. My other realisation was that it is very easy for the SLA friendly party to argue their case, because it is so damned logical and makes so much sense, and that it is really hard to present an opposing argument without coming over as someone that either has something to hide or just beeing a total ass.
SLA’s is a two-sided blade, but it is rather dull on the deliverer side an overly sharp on the customer side. It does not create any value (as such) and totally prohibit innovation and agility. So why do we do it? I think because we do not manage to think about our relationships as partnerships where both parties have the same objective and interest. We may say we do, but we constantly fall back to a traditional model of total war between customer and vendor. We use SLA’s as a tool to wip our assets and resouces into submission, putting them in their rightful place. Should we try freedom instead of slavery?
A really great comment, Dag. I often find SLAs used as a limiting tool – e.g. where the service provider points to the SLA and says “well, we’ve done all it says” when the customer is red hot angry. Or, the customer demanding some stuff done dictated by the SLA when that is no longer needed or perhaps never created value in the first place. An agile partnership is the way to go. What makes the customer happy is changing – and faster as technology and social ways changes faster. A service provider that is focused on the customers goals and the expansion for the customer is worth his weight in gold.
For a moment I mis-read you next to last sentence and instead of “We use SLA’s as a tool to wip our assets…” I read “We use SLA’s as a tool to wipe our ass…”. Maybe that is how it should be 🙂
As for “Should we try freedom instead of slavery?” – I go for freedom every day of the week and twice on Monday.
Did you read the article, “Processes, Automation and Human Potential“?
Nice post 🙂
SLA = Service Level Agreement
Service in ITIL = Delivering customer outcomes ie. what comes out of the delivery for the customer.
SLA = Agreement on the levels of delivering customer outcomes
Why then does the provider of the service usually present a SLA showing measurement of the availability of an internal server? Eg. 99.1% availability. Unfortunately the .9% = 6 hours 41 minutes 45 seconds that month of allowed downtime were right in the middle of a vital operation for the customer.
Out with the SLA and in with delivering amazing customer outcomes.
DISCLAIMER: This may mean that you actually need to talk more to your customers.
I’m in IT too – a Unix sysadmin working in Infrastructure at an ISP. When my stuff stops working, the Internet stops working.
The current fashion fad at work is SLAs and ITIL, and we (my team that is) also use them as “a tool to wipe our asses”, for the same reason you do.
The most interesting part of your reply to me is this: “it is very easy for the SLA friendly party to argue their case, because it is so damned logical and makes so much sense” and I see that too. I try to argue my case, I quote truths like “This team has been in existence for 14 years and we have ZERO downtime of the systems as a whole”.
I’m sorry, I lied there. Downtime WAS zero, recently it became not zero. Why? Old hardware made a critical system come crashing down due to no budget to replace hardware. But that’s OK, as the number is still within some range sucked out of someone’s thumb and the SLA applies. However, service delivery suffered badly.
I thought long and hard about why this is so, why it is that a process like ITIL always gets traction even while any fool can see it doesn’t actually work out in the end. I found some answers:
1. ITIL is a process that people use so that something else can think for them.
2. You cannot put a process (or software) where a human belongs.
3. You cannot put a human where process (or software) belongs.
4. You cannot use a certain process to get a certain result (I have Geir to thank for this one).
When people follow process, more often than not, they want to avoid their responsibility or diminish it. Instead of doing their part of the process because it works and they can see it does, they do their tickbox on the form because the tick box says they must. Apparently, $SOMEONE_ELSE will come along and do a $REVIEW and $OBSERVE and $FIX_BROKEN_BITS and this all happens $LATER.
Note the sarcasm with the variables 🙂 They are there because those things simply never happen. The process does not highlight that part as being the most important part of the whole story! It’s a case of people use it to put a process where a human belongs.
I don’t disagree with process per se. It’s really hard to commission a core router without a written guideline as to all the other configs and systems that need to know about it so systems work smoothly with the new addition. By process can never replace thought.
I’ll end on a funny observation. I’m middle aged and can get away with being blunt, so I do it a lot. many many times I’ve flaunted process and got the proper result anyway. I often get asked “Did you do this contrary to rule XYZ.1.2.3?” I answer “Yes, I did. I fixed stuff. What you gonna do about it?”
And nobody ever seems to argue further… they just mumble and walk away. I thought it’s because they don’t have a bullet point in their process about how to deal with a sysadmin who’s prepared to take responsibility and do what needs to be done 🙂
:clap: :clap: :clap:
And as Brendan mentions above; if you deliver amazing customer outcomes, then why use an SLA or any kind of binding contract? Ask the customer and deliver what he wants and needs.
Another viewpoint: Nikola Tesla, an unrivaled genius. He had a contract which didn’t benefit both parties. And his altruism led him to tear up the contract that otherwise would have made him the world’s first billionaire. More on Tesla here: https://isene.me/2013/03/24/in-support-of-libre-knowledge/
Got me wonder what the real purpose behind an SLA is?
Anette: Got me wonder what the real purpose behind an SLA is?
Chris: Steady and predictable monthly income for the vendor? Imaginary peace of mind for the buyer?
And a status quo for all
From the ITSkeptic book
“Some organisations give high importance to how long IT is going to take to resolve incidents, and they write this into SLAs as a key metric. Usually high priority incidents are to be resolved quickly while lower priority incidents can take progressively longer.
This is akin to firemen promising to extinguish three-alarm fires within ten minutes but a backyard grassfire may take until tomorrow. It is absurd on three levels: extinguishing the fire takes as long as it takes, bigger fires take longer, and that little yard fire won’t be so small tomorrow.”