I’ve mentioned before that I think a lot of the ‘SLAs’ in place are really not helpful or really of sufficient quality and value. Very often that’s due to the fact that these are created in haste or with little understanding of SLM and its objectives and value. However also its because we’re asking the people doing them to create the Service Catalog at the same time…
As a guide for how not to do SLAs here a list of some examples (fictitious but all based on typical examples that I’ve come across) of why SLAs are still poor and its no wonder why IT and business people alike don’t have faith in them…
ICT accepts no responsibility whatsoever at any time for anything it might or might not do.
The person of the first party shall be ICT, pending approval from the ICT Steering committee. In respect of the second party this should be the user community as appropriate.
Too many unnecessary quasi-legal statements, plus disclaimers, caveats and general Pontius-Pilate-like distancing from ownership and responsibility.
SLA performance is not guaranteed, but is expected to reach 60% of 90% of the agreed target, except when the DBAs and Network team are at the pub.
I really hate this one – an SLA target is a target, so let’s not build in ways that we can slip out of it or set reduced targets. Better to miss the target and use the info to support a business case.
The Service Desk reserves the right to ask unreasonable questions about serial numbers, otherwise all contact is invalid.
IT will respond in a timely manner to high-priority business incidents, if they are asked very nicely indeed and also made to feel very special and important.
IT reserves the right to send meaningless automated emails to users at any time.
Requests for PCs will be delivered within 6 months or at least before the requester leaves the organisation – or whichever is most convenient for the IT department.
System availability will be 100% when not required, patchy at key business times, which are not agreed or understood.
Sometimes IT can come across as just plain arrogant and not listening to its customers
Query response times are expected to be sub-second, unless there is excessive run-time load from QRG tables on the JTAG server in X/DOPP. XSPART nodes are enabled, except under BS/0906688, including calls to the monkfish database.
Often you find unnecessary technical jargon – or just plan gobbledegook – that is meaningless and patronising to the audience. Plain language is preferred…
This SLA document is binding and any breach of the aforementioned conditions will result in immediate dismissal and summary execution.
Sometimes it seems like the IT department have become lawyers or issuers of retributive punishment. Sure, we need to establish customer responsibilities, but within reason.
This SLA will be filed for reference and stored in the private folder D://unused/garbage, marked ‘Do not read’. In the event of it being read it will become invalid.
Issues or complaints should be escalated to the least responsible person available, and will be ignored.
I’ve read a few SLAs which seemed OK until right at the end there was some sort of disclaimer which really made me question whether anyone had actually bought into it. Escalation and ownership should be clearly defined – there’s also nothing like getting the relevant business level owners to physically sign the document. The SLA must also be a living document and not simply filed and ignored.
I hope you might find these helpful or at least raise a smile or 2.
I used these at a Service Catalog presentation recently, where the room was split between those laughing and smiling knowingly, and those looking slightly uncomfortable and scribbling hastily whilst shifting in their seats…
