At last week’s itSMF UK conference #ITSM12, there was a lot of discussion about the value of SLAs – this continued on Twitter and Back2ITSM afterwards…. Certainly there was a call for the abolition of SLAs – which seemingly was well received in the room at the time. Here’s my quick take on this….
SLAs as they currently are defined and implemented in most organisations (in my experience) are rubbish – poorly defined and implemented, IT-focussed, badly written, not related to business outcomes or value, negative, fault and issue focussed etc. etc. See my #ITSM12 and other presentations for a slightly wry take on the ‘SLA Small Print’…
This is not to say that the SLA concept is wrong or bad or misconceived – however the way SLAs have been implemented has been poor at best and this has resulted in weak SLAs and a negative image for this process. I think this is now changing with the development of Service Catalogues and Portfolio Management and an improved understanding of Service Level Management in general. However the image issue persists, based on the results of implementation, not the concept itself.
The issue has mainly been a misunderstanding of how to start and the fact that most organisations start with SLAs rather than defining services. It is also the case that many IT shops have completely missed the point and opportunity here – that is to get out and talk with and listen to their customers. The essential point and value of SLM/SLAs/Service Catalogue/Portfolio Management/BRM – whatever you want to call it as a wider discipline – is that IT people need to get out there and engage with their customers, understand what they need to do their job, understand more about the business environment that they operate in, learn more about the specific priorities of their customers etc.
The real point here is that it is the PROCESS OF DEFINING SLAs that is important and which delivers value, not just the piece of paper which represents the SLA and/or Service Catalogue. I’ve worked on a number of projects where there has been no signed SLA at the end, BUT both parties learned a lot from the process of engaging with each other and learning about what they did.
So whilst I agree that there are a lot of really terrible SLAs out there, let’s not throw out the baby with the bathwater and trash that process as a result. We work in business not ‘in IT’ and we need to reflect that in some expectation of how we will support business and deliver value. SLAs and SLM are important as much as a catalyst than as a product and process. Let’s remember that and try to develop how to do this better and with more successful results – but let’s keep talking and listening most of all….


  • SO where are these good SLAs, and what would make a “good”SLA? When you discover that something that works in theory almost never works in practice – or at least only under very artificial conditions – then it might be time to revise both the theory and the practice. Over the years I’ve negotiated many SLAs and reviewed hundreds and I can honestly say that even the best one s have been sub-optimal solutions.
    First the right conditions for the perfect SLA to be negotiated, agreed and used only occur very rarely. I suspect that when those conditions actually occur the need for an SLA is already redundant. As I’ve said the only time the customer asks for SLAs is when IT is consistently failing to deliver against customer expectations and the underlying reasons why IT is failing to deliver will often infect the SLA creation process.
    There is an argument as well that SLAs capture the letter of the law, but not the intent, and as we all know setting a target can distort behaviour in unexpected and undesirable ways.

  • barclay says:

    I know what you mean here, although I also know that there can be a good outcome from the process. None of the ‘SLAs’ or relevant document are ever particularly exciting, but i never really talk about ‘SLAs’ with the customer, more about how we can improve (@stuartrance also works this way).
    From the outside, to me the success is seeing IT and business people engaging and always learning new things about each other, and reflecting this in some formal or semi- formal agreements and documentation.
    How we then turn turn that into generic documentatiion is subject to the variations across organistions and can be really useful or also not useful at all… Of course I’m happy to share more examples if and when appropriate…