At a recent ITSM event I was speaking with another practitioner who said that they were looking to implement service level management. The challenge was that as he was describing this activity he was developing a crinkle in his forehead from the forlorn look on his face. I asked him if they were in a good position to move forward on this and he said “our CIO thinks so… he thinks we would be in a better position to provide service if we had some service level agreements put in place”
The first question I would ask is whether you had a service catalog in place. He indicated that they had something but nothing that was managed or formal in a way that was usable. I went on to explain that the purpose of ANY catalog, service or otherwise, was to outline what services were provided. To do this you really need to know what the business needs. The other thing is to start looking at this from the business perspective as well. What ‘services’ is the business consuming.
This takes us back to the original statement made by my colleagues CIO “if only we had some SLA’s”. keep in mind that the first word in that acronym is service. So in reality we should have a really good understanding of what the service is all about.
When looking at the definition of the service and all that applies we should be able to keep it pretty simple. In fact all the details of what the service are, including things like; what it does, when it is used, by whom, when maintenance can (or cannot be done), are easy enough to be understood by the business who consumes the service.
To do this you need to communicate with the business
It seems obvious enough, the trouble is that in some cases IT makes assumptions that they know and understand the services that they provide when in reality they are not as informed as they think. This assumption is typically the piece that is the issue when implementing service level management.
The key when looking at this is to look at how we provide service in a basic way and communicating with those who are using the services. Unfortunately IT overcomplicates things which are half the trouble.
In the beginning get the content from the business with their goals or outcomes in mind. Also get the information captured and validated in their terms rather than the IT (technical) viewpoint. Getting the business input might be a challenge if this hasn’t gone well before the key is to market this in a way which outlines how the success will be achieved and how their input and participation will directly contribute to that success.
Once you get these requirements down make sure that they are visible (not hidden away in a group share) and that they are in the same terms which were discussed with the business. Resist the need to make this a technical document.
When you get it built you need a way to keep this current. Where it applies make sure that you integrate other service management processes to input or take the outputs of service level management. To help with keeping the process on track make sure that you have appropriate reporting to outline areas where things may not be going well so you can correct them. Also make sure to celebrate your successes where you find them.
This methodology applies to any service catalog initiative, not only IT.
This methodology applies to any service catalog initiative, not only IT.
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn