Meaningful metrics in ITSM: it’s about the business (stupid)

The traditional problem is based on IT organizations believing the world revolves around them rather than looking at things from the perspective of those they serve – or at least asking them what they think.

And IT/ITSM is stubbornly slow to change, with many large, process-driven organizations reflecting 1980s-1990s ways of working. Yes, there are fewer people in IT leadership roles who could be accused of neither knowing nor caring about how to improve, but I’ve still witnessed people on service desks reluctant even to answer the telephone.

Being kind about it, the principles of collaboration for the achievement of business goals are not widely implemented. To be blunt, there is poor understanding of what that means or how to do it.

The focus has been skewed towards best practice rather than business quality, resulting in a gap between “doing the right thing averagely” and providing what organizations actually need.

IT and ITSM professionals could do themselves a service by consistently demonstrating value; to do that means reporting on the things that matter to the business.

IT departments are being hit with greater demands from their customers for better reporting.

This means a shift away from rummaging around “under the hood”, producing a lot of stuff people don’t need to know but gets reported anyway and creating befuddled business people.

The service level agreements (SLAs) of today that capture the attention of a business are those that demonstrate value. So, it’s out with support SLAs (quantifying system availability, for example) and in with metrics that reflect the specific jobs that people need to do. It’s not about servers and help-desk statistics but indicators of how well the IT department is aligned with the wider business and its goals.

A watermelon is not only a big green fruit with a red interior, it’s a useful metaphor for SLAs gone wrong.

Like the watermelon, SLAs can appear green on the outside (if you’re using a traffic light system to measure performance) which suggests you’re “doing quite well”. But, if you delve beneath the outer shell, you might find the customer experience is as red (i.e. appalling) as the flesh of the watermelon.

The risk of poor SLAs is that IT can believe it’s doing the right things when it’s actually failing and becoming more disconnected from customers. The knock-on risk is that the business makes a bad decision to outsource IT based on customers’ dissatisfaction.

SLAs that are too focused on recovery from failure – a.k.a fault fixing – are not really defining value and are inherently negative. This doesn’t do justice to what the business needs or help anyone to understand what IT is doing.

Before getting to SLAs, IT/ITSM needs to define the service catalogue: this is about getting under the skin of what an organization does and what services IT needs to provide.

It could mean bundling services together based on how a department is using IT: for example, the finance team might be using SAP or various other accounting tools which can be bundled to combine system availability, customer satisfaction, and “moments of truth”, such as ensuring regular payments on a particular day in the month are conducted smoothly. The metrics will be built into the SLA and IT’s part in delivering that.

To emphasize how an SLA should reflect what an organization does, take the ambulance service: having the right telecommunications and devices functioning properly will affect how long it takes for an ambulance to attend an accident. This couldn’t be more linked to organizational needs.

Crucially, an SLA must be collaborative; agreed between IT and the operational end of the organization rather than being handed down unilaterally.

• Ask the question: what do we do?
• Get your services onto one page
• Build up a picture of what’s involved with the services
• Pull together the IT view of the world and the wider business’ view of the world
• Identify what areas need greater resilience
• Decide what could be outsourced as a commodity service
• Structure the way you work to get the right reporting data
• Reviewing your categories: it’s better to have 10 useful categories than 300 categories that are never used.

SLAs shouldn’t be the life and death of the relationship between IT and its customers. But the right SLAs will usually create the by-product of much better understanding of what customers do and a much closer relationship with them.

With a better quality of data in the reporting metrics, an organization is able to make more informed decisions based on the right criteria: looking at services, defined customer groups and defined outcomes to assess whether there needs to be more or less investment based on the value delivered to the business.

Getting human to human in ITSM

Tackling the rise of bimodal IT and 'two-speed ITSM'

What should IT Leaders be focusing on in 2015?