Branimir Valentic I have witnessed a situation where an IT department designed and implemented a service that they find useful and functional. And, no one else. The result was that resources were spent, service was implemented, but no one ever use it. The point is that the service was not something the customer needed, meaning – the service did not create any value in the customers’ eyes. I’m pretty sure that each of you will find similar examples.
These days, people working in IT are pretty self-confident, particularly if they are in the same company for many years. And, they think that knowing the business or customers gives them the right to know who needs which service and why it is good for them. I would say – stop before you begin with the creation of such services or process changes. It’s not IT who sets the pace – it’s the customer. But, what do they care about? What’s important for them? Let’s see the customers’ view and learn the ITIL approach to reducing the gap between customers and the IT department, i.e., IT service provider.
Value
The fact is that it’s the customer who decides what is valuable or not (i.e. what creates value) to them. Not the IT. Maybe this statement sounds simple. But, my experience shows that, quite often, people in IT comment various situations like “How they (users) don’t understand this’”, “How come they don’t like this functionality?”, “If they would use this application, their life would be much easier.”… Honestly, from time to time I have also high expectations from my customers. I see the world with my eyes and not with the customers’ one. And, that’s wrong. To understand this thesis, let’s consider the definition of value – “The benefits delivered in proportion to the resources put into acquiring them.” From customers point of view – resources they put to acquire a service(s) are usually money they pay for the service(s). But, more important is – benefit they get. Since customer is paying for the service(s), they will decide whether the benefits gained are worth it.
To get a better understanding, imagine you booked your vacation, you just arrived at the hotel, and you start gaining impressions. Well, there could be the best-designed catalogue of that destination or sales person who is highly professional in selling tourist arrangements, but it’s you and your impressions who will decide whether you like the hotel, destination, offerings… It’s the same with IT customers and the services they use.
Read the article ITIL strategy – Framing the value of services (part I) to learn more about value.
Utility
Utility, or functionality, is what the service does. The point is that your customers need your services to do something. And, they are the only ones who know what exactly they need to do – that’s their expectations towards the IT service(s). To gain a mutual understanding (of what creates value to the customer), you should talk to them and describe the functionality as detailed as possible. And, first of all – listen to what they are saying. Don’t try to record the customer’s description in a way to support your view of the functionality. It’s the customer’s view that is important.
Utility should answer the question: “What does the service need to do?” Functionality of the service is just one half of the value description. Another one is the description of the customer’s requirements, or warranty.
Read the article Service Level Requirement (SLR) as origin of the SLA content to learn more about service level requirements.
Warranty
Warranty describes how well the service is working. Namely, you can have the best service in the world (from a functionality point of view), but if it doesn’t deliver at the level the customer needs – it’s useless. And, again, it’s the customer who knows what kind of service he wants to get. Here we talk about design of the service and the parameters that describe it. These parameters are security, service continuity, availability, and capacity.
All those parameters need to be defined unambiguously and (if possible) in measurable units. In such way, you will avoid future misunderstandings. Parameters that describe warranty are usually a good foundation for the Service Level Agreement (SLA). Warranty answers the question: “How is the service delivered?” However, ITIL recommends that warranty should not be seen separately from utility, meaning design of the service has to have a tight connection with functionality. I know, it’s logical, but also many times omitted.
Read the article ITIL – Service Level Agreements: Designing frameworks to learn more about SLA.
ITIL as an enabler
The value that the customer expects can be achieved only when the service meets customer expectations (in the form of utility and warranty). But, there is one pitfall in this statement. What often happens is that customers are concerned about functionality and forget about characteristics of the service, i.e., warranty, until the service enters the live environment. You, as an IT service provider, should have established the IT Service Management (ITSM) structure (using ITIL will enable you to do that) and taken care about all warranty parameters right at the beginning of the service establishment. You gain because of the satisfied customer, and the customer gains because they will get value to the full extent and they will get a feeling of having professionals “on the other side” (meaning – you).
Let’s resume – a service has value when it enables someone to do exactly what he needs to do. ITIL puts high importance on understanding the customer’s requirements and demand for functionality. During the whole service lifecycle these parameters are the cornerstone of all further activities. For example, ITIL recommends not continuing with IT service implementation until all parameters that describe the service are known and agreed with the customer. And, that’s logical. Mistakes made later in the service lifecycle (e.g., just before going live) can be quite expensive, and I’m sure no one wants that.
Use our free ITIL Gap Analysis Tool to check your fit with ITIL recommendations.
