The level of quality in providing a service can either be the source of building trust with the service consumer or the main cause of dispute.
For example, if you have an application for which you didn’t fully agree the criteria for software usability – and the software usability is disappointing or inadequate – you have a recipe for never-ending disagreement.
This is probably the primary reason why it’s critical to define and agree service quality from the very beginning – and ensure that there is mutual understanding, definition and agreement about what quality means and how to measure it. Too often, service providers and consumers have different interpretations and expectations that result in dispute.
Meeting stakeholder needs with ITIL 4 software development and management
The software lifecycle within ITIL® 4’s software development and management practice offers a holistic approach to ensure applications meet internal and external stakeholder needs.
This approach is important as it helps the service customer to ask the right questions based on what their requirements are. They can’t just rely on what the provider proposes but need to understand and agree on each element of the criteria. The ITIL 4 management practice addresses these criteria, including functionality, reliability, maintainability, compliance, auditability, utility vs warranty requirements, usability and security.
Ultimately, it’s about giving customers what they really need and agreeing on defined quality levels. Then, if the services need to change, you can deploy ITIL 4’s service validation and testing practice to be sure that any new or changed services still meet the defined requirements.
Challenging and going through the acceptance criteria to validate change is, indeed, the moment of truth: do you have agreement or a dispute on your hands?
In one example, a software development company wanted to create an application to store and access historical company information. On the face of it, what the customer wanted was clear in terms of functional requirements.
However, during the first test of software functionality, the customer said it was OK, but had expected a user interface similar to LinkedIn. Nobody had defined these requirements before and, essentially, time and money had been wasted because the desired user interface wasn’t defined at an earlier stage in the cycle.
This shows how important it is to define exactly – from the user’s perspective – the software’s usability and service quality to avoid misunderstanding. And if you can’t commit fully to customer expectations, you need to agree in advance the available level of quality.
Measuring service quality
The level of service quality a provider delivers enables the customer to get the value they want. However, measuring this goes beyond meeting the defined quality criteria.
Measuring value created by using the “outside-in” approach – how stakeholders view the value a service provider creates – includes the view of the customer in the measurement process.
For example, if a new application simplifies the way a salesforce can make appointments with customers then, thanks to the application, the sales team can schedule a defined number of meetings per month. This measures the quality of the service, the value it delivers and justifies why they pay for the application.
Such evidence of quality and value goes beyond the culture of just meeting a service level agreement and increases trust in the service provider.
Investing the time to define the quality required of a service will significantly influence the outcome for both provider and customer and dictate the expected benefits.