![Advisera Branimir Valentic](https://advisera.com/wp-content/uploads/blog_authors/branimirvalentic.jpg)
March 21, 2017
It’s probably happened more than once: an IT service achieves Go-Live maturity, only for you to figure out that it’s not what the customer asked for. That’s bad news. The good news is that it could have been the customer who discovered that, instead of you. Whatever the case is – it’s wrong, and it shouldn’t happen.
IT Service Management (ITSM) based on either ITIL or ISO 20000 encompasses (of course, if you have adopted it) the whole lifecycle of the IT service. And, one of the first steps is to talk to the customer or the business and see what they are looking for. These requirements, at this stage, are still business-related. Once you know what your customer is looking for, it shouldn’t be hard to continue and quantify those requirements. And, there you go – you can describe those requirements from a service point of view. These are your Service Level Requirements (SLRs).
The ITIL and ISO 20000 definitions of SLRs are not that clear, and hardly emphasize the importance SLRs have in an IT service lifecycle. The point is, if business requirements (which are prerequisites in order to define SLRs) are not clear and well defined, it’s difficult to expect that the service will fulfill customer expectations. So, to be sure that the service delivers what the customer requires, you need to set up the requirements right from the beginning.
So, as you can see – SLRs are pretty important. Therefore, the logical question is – who is responsible? SLRs should be coming from, and are agreed on with, the customer. There are two processes whose jobs are, primarily, related to customers: Business Relationship Management (BRM) and Service Level Management (SLM).
If we have an existing service, then the Service Level Manager (who is permanently in contact with the customer) will be actively involved in SLR definition.
While defining SLRs, Service Level Management is responsible for ensuring that they are defined and agreed on with the customer, in detail. Further on, SLM is responsible for management of the SLRs until the service reaches the operational stage. The SLRs could change with time (i.e., until the service reaches the live environment); therefore, SLM is responsible for managing the SLRs. SLRs are related not only to new services, but also to changes to an existing service.
SLRs make clear what the “rules of the game” are. If you start developing, e.g., a new service based on a few conversations with the customer – that’s a road to disaster. Sooner or later, your point of view and that of your customer will differ. And, it’s really hard to get out of such a situation. Therefore, SLRs are used for:
Although it seems that the definition of SLRs is a complex job – it really doesn’t have to be. To make it easier, the people involved in SLR definition should not do it by themselves. There are experts in the IT organization who should support them, like people from Capacity Management, Technical Management, Application Management, etc. This offers two benefits:
SLRs are the foundation for the SLA (Service Level Agreement). That means that, while developing the service, SLRs will be refined and once you get to the deployment phase – SLRs will help you describe the service in measurable value. That makes perfect content for the SLA. Since the SLA is used while the service is operational, this means that SLRs are the controlling factor on whether the delivered service fits the customer requirements.
Although some may not like it, investing significant effort right at the setup of the service (or change to an existing one) will be rewarded throughout the service lifecycle. Poorly defined SLRs are a source of failed implementations and arguments with customers. Firstly, let’s say that the customer is always right. Fine, but document what “right” means (SLRs, in this case). And secondly, correcting something that was wrongly implemented creates additional cost. Costs are increasing as a service progresses throughout the lifecycle. So, it’s hard to decide which argument is better (or worse), isn’t it?
Use this free preview of a Service Level Requirements template to see what such document consists of.