Branimir Valentic 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).
What are the 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).
When we are talking about the process of defining SLRs for a new service – they will be defined during the service strategy phase of the service lifecycle. Usually, the people who are managing the service portfolio or someone from Business Relationship Management will define high-level SLRs, which are needed (and, usually, enough) to make a decision – go or no-go with the service. Later, SLM will take over and refine the definition, including, as much as possible, measurable SLRs.
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.
What’s the use of SLRs?
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:
- Foundations – define SLRs as a foundation for design of the service.
- Don’t wait for the customer. Be proactive and suggest – what could be expected, i.e., what is realistic, what does best practice say, which performance is achievable . . . but, don’t over-promise.
- Match SLR to delivered service.
- Be exact – avoid explaining what the SLR is, but try to define a measurable parameter. In such a way, you’ll help yourself – but also make your customer’s life easier (although they may not see it at the moment when SLRs are negotiated).
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:
- Increase in competency while defining SLRs – the customer will appreciate that as well.
- Future phases of the service lifecycle – once you define the service and related SLRs, design will take over. Those same experts are sitting somewhere in design and they will take over. The better the SLRs are defined right from the start, the better and easier design will be.
What’s the importance?
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.
