Neven Zitek So, you have customer, with a signed Service Level Agreement (SLA) and a good relationship with him. Excellent! Can you imagine how many customers are served without an SLA? Many.
There are different reasons for such a situation, but one thing is certain: it’s not good. I often hear explanations like, “We’ve worked with the customer for so many years and there are no disputes, everything runs well… so why bother?” This statement is partially correct. When there are no disputes – there is no need for a SLA.
But, what is often forgotten is that the SLA defines many operational processes, procedures and parameters, for example: how the incidents will be handled, or which measurements (and how frequently) are needed, availability of the service… etc.
Roots
Usually, there is a SLA template and all you have to do is adapt it to the service for which it will be used. And then the brainstorming starts. Where is a description of the service? What are the availability requirements? How about security? And many others. Basically, when the service has to be operational in a live environment (which brings a lot of activities and issues to solve), you start asking questions which are going far back in the service lifecycle. An even worse situation is when the SLA is signed much later after the go-live. What I want to say is that the later the building of the SLA starts, the more complicated it gets.
Luckily, such a “headache” can be healed. The fact is that the service does not come from nowhere. It is carefully prepared before it goes live. And that’s the chance to start preparing the SLA, i.e. its content, much earlier.
Service Level Requirements
Customer requirements (as a result of fulfilling customer business needs) are the basis for the service. By documenting the customer’s requirements, the Service Level Requirement (SLR) is produced. The SLR is made in the form of a document that will serve as the basis for the future SLA. The SLR should describe the service, i.e. how the service should deliver what was required by the customer (defined as warranty of the service), e.g. what is the capacity of the storage to satisfy the customer’s requirement for e-mail service.
The result of the defined SLR will be service level targets, i.e. what must be achieved to fulfill the SLR. This is where we go into a deeper description of the service. To describe a service with all its parameters – sounds difficult, doesn’t it? And it is. Therefore, many other processes need to be consulted before finishing the SLR document. This means also operational processes (e.g. Incident Management or Problem Management process). Another good idea is to set service level targets as measurable as possible. In this way, later misunderstandings will be avoided.
SLR throughout the lifecycle
SLR is not a one-time job. Let’s take new service as an example.
Already in the service strategy phase of the service lifecycle there is enough information to start building the (at that stage – business-oriented) SLR. Service Portfolio Management, Business Relationship Management and Financial Management processes will be essential to defining the first requirements (in this stage – high-level). During the design phase of the service lifecycle, there are many processes that contribute to creating content-rich, i.e. more detailed, SLR (e.g. Availability Management, Capacity Management process …etc.). Usually, during the transition phase, many tests are performed. The SLR is a live document that will be constantly fine-tuned, because during the testing many new details will be discovered and the requirements will be updated. Yes, it sounds strange – “requirements will be changed.” Well, customers usually have an idea about the functionality (“We need to support a certain number of simultaneous payment transactions.”) and it’s up to us to fulfill such requirements. It is hard to predict everything during the design, so that’s why the SLR may be refined during the transition phase.
When the transition phase is over, we have a complete SLR document, which is an excellent basis to create a detailed SLA. The SLA should be rich in content and, throughout the lifecycle, we defined enough parameters to have a good foundation to build the SLA.
Figure: Influence of some of the processes on SLR and SLA throughout the service lifecycle
Customers and the process
Service Level Management (SLM) is the process that takes care of both the SLA and the SLR: from the beginning (determining and negotiating), through revisions until the SLA is created.
Since there is a customer requirement where it all starts – it’s a good idea to involve them from the beginning. There are several reasons for that:
- They like to be involved and feel constructive.
- They are paying for the service, so they have the right to influence the service.
- Clarity – when they are involved from the beginning, there are no details that need to be clarified and can change, e.g. the design of the service (which can happen if you leave customer interaction for the end).
- In such a way, the customer is also the “creator” of the end result – so there is no danger that they are not satisfied with the end result.
We all like our customers, and therefore it will be nice to have them while creating the service from early in the service lifecycle. But, that could be dangerous and therefore – be careful. If you involve them in every single detail – the sky won’t even be the limit anymore. Their requirements will balloon and your Financial Management process will signal overspending. And you – you will fight very hard to get the project under control.
To gain more practical insight, download this free sample of a Service Level Requirements template.
