Frankly who cares about how many incidents have been logged, responded to and resolved within a particular timescale, or what the % system availability is, or how many requests for phones have been received? We need to measure these things, but in this form they are only of value to a very limited group of people - i.e. within IT. The fact is that most of the SLAs I've seen are basically IT-focused, so of no interest to their customers and of little real prioritizing value to IT.
Generally it’s a thankless task for whoever has been dumped with the job of setting these up, as they have to convince sceptical customers to participate in the project, where they assume they will be simply given what IT wants to give them. On the other hand the ‘SLA-monkey’ has also to convince even more sceptical IT people that it’s a good idea to have targets and to be measured - they assume this could lead to them being fired or tortured or shot, so they get very defensive.
It's not that I think that SLAs can't be of value, or that they are all bad. I do think that SLAs and the SLM process are the central core of IT Service Management, providing the business mandate for service delivery. However it’s just quite rare to find organizations where this is really understood and reflected in their SLAs - especially in terms of how this is presented to customers.
The problem basically comes down to (lack of) knowledge and understanding of how to make this work - its actually quite difficult to get this right and to provide value, however it can be too easy to simply fall back into the comfort zone of doing what we know, rather than what is needed and good for the business. I think ITIL and the industry has been slow and poor at really providing clarity and good guidance on how to do this, although this is definitely changing and improving. However there’s been very little real practical advice available on how to make this work.
To me there are 2 main problem areas:
(1) SLAs being defined without services being defined or understood
(2) Little real understanding of how to build and negotiate services and SLAs
How do we deal with these issues?
(1) If we start to simply try to build SLAs, we inevitably start to also define the services and Service Catalog, even if we don't mean to - how else can we set up a Service level agreement without some definition around the service that this is referring to? This of course makes the task much more difficult, particularly if the person doing this doesn't realise that that’s what they are doing!
However if you start with Service Catalog and service design/definition then it makes the negotiation part much simpler and easier to focus on. It also means that you will have to think through the ‘supply chain’ part of IT Service Delivery and engage with all the relevant managers and teams who form part of that chain. Generally its easier to get these guys to sign up to an SLA if they have first been gently introduced to the concept of the ‘service’ bundle and their part in it – it’s way too easy for them to push back on the SLA without it.
(2) In terms of guidance and experience this has tended to be left to individuals and ITSM consultants to develop methods and models for defining IT Services and implementing SLAs. Like many others I have developed and honed some tools and practises for this over the years and learned from mistakes. There isn’t really a standard model for doing this however and many poor souls are left to their own devices to work out how to set these things up and usually take a lot of stick in the process.
In recent years we have seen better proliferation of tools and functionality in this area and more clarity about the various components of a service catalog – e.g. providing different levels and views (user, business and IT) of services as appropriate to different interested parties.
However the central core of the service and SLA still have to be thought-through and delivered in practical, useable and relevant format and this still needs some guidance for success. Here’s some simple tips:
How do you make your SLAs loveable?
Keep them short and concise – otherwise no one will read them. Also the more summary that they are the more chance that you will have worked through they key elements – i.e. rather than producing lots of detailed technical information
Use simple and appropriate language – you don’t need to suddenly start writing as if you are an attorney! Use language that speaks to its audience and doesn’t try to dazzle or blind with legalese or techno-speak – that just annoys your customers.
Keep the SLA realistic and achievable – but don’t be waylaid by IT guys trying to get everything 100% tied down – you can’t plan and SLA every possible eventuality. It’s a balancing act between getting something agreed and delivered and also not being too bland or predictable. – SLAs are targets!
Only set up an SLA that can be measured - you have to ensure that anything that is defined is also capable of being measured in some way, otherwise chaos reigns.
Ask the business what they want – or what they think their services are – you may be surprised at what comes back that is then useful to you in terms of IT prioritization. I’ve worked on projects where the SLA delivered wasn’t really great but the process itself helped IT and the business to come to a much better mutual understanding.
Keep smiling – running an SLA project doesn’t always make you popular – although when it works it’s a great feeling. However the key point here is that the SLA delivery role requires great communications, diplomatic and project management skills – and a thick skin!
So I don’t really hate SLAs – but let’s start loving our SLAs by making them better!
