Right now, with the growing corporate and employee reliance on technology to function, and increased technology adoption through digital transformation, your organization’s IT support capabilities are more important than ever. Meaning that how you measure and improve performance is too, with your IT service desk’s key performance indicators (KPIs) and metrics vital to its success. But are you employing the right IT service desk measures?

For instance, is first contact resolution (FCR) a good KPI for your IT service desk and incident management? Many corporate IT organizations think that it is – after all, it’s definitely one that’s prominent in the ITIL books and is popular with many IT service management (ITSM) consultants. But is it right for every IT organization? And what about the many other measures that are currently employed by your IT service desk?

Assessing the suitability metrics using FCR as an example

On one level, is it just a measure of closed calls or of the percentage of end-user issues that were given proper care and attention? On another, what’s included in FCR stats? Just easy incidents, including password resets? FCR can be fiddled with, and I’ve even seen service desks that add room bookings into their FCR calculations. Are trickier issues disallowed for “fairness”? And I bet some would include wrong number calls if it made their FCR stats look better. Plus FCR, along with other ITSM KPIs and metrics, can definitely drive the wrong staff behaviors.

However, the real issue for me is that IT organizations need to understand what they’re trying to achieve before they can define their KPIs, including FCR. So, picking up an industry best-practice KPI and making important decisions based on it might not be in the best interest of the company using it. I’ll come back to this. First and foremost, IT organizations also need to understand what KPIs are, and their use.

What’s a KPI?

The easiest place to start is to look at the KPI acronym and what it stands for, or at least what it should stand for:

• Key. Most organizations will struggle to measure and report on every possible metric and, if there are too many, then the less important ones will most likely distract organizations from the key ones that they really need to focus on.
• Performance. A KPI should help organizations and teams to understand how well they are performing, and each KPI should help them to focus on a critical success factor (CSF) that needs to be achieved.
• Indicator. A KPI is not proof that something has been achieved – it’s simply an indicator that suggests how well you are currently doing. Achieving KPIs is not the end goal, it’s simply a tool to help organizations to focus on their activities, to implement remedial or improvement activities as needed.

Don’t Confuse KPIs with CSFs

Wow, us IT people really love our 3LAs (that’s three letter acronyms)!

CSFs are the things organizations or teams must achieve to help meet their goals and objectives. These may not be directly measurable, but it should be very clear how they contribute to success. Some examples of CSFs for ITSM processes include that:

• The business is protected from the adverse impact of IT change (a CSF for change management (or change enablement using ITIL 4 terminology))
• IT service downtime doesn’t have a serious impact on the affected business service or process (a CSF for availability management)
• Workarounds reduce the business impact of problems (a CSF for problem management)

And although IT organizations might not be able to directly measure these CSFs, they can discuss them with their customers and other stakeholders, and agree that this is what you are trying to achieve via ITSM.

CSFs in ITIL 4

In ITIL 4, CSFs have been replaced with practice success factors (PSFs) but they’re still ultimately CSFs (and I’ll revert to the use of CSFs after this section). For example, one of the PSFs for change enablement is “minimizing the negative impacts of changes.” One of the PSFs for availability management is “treating service availability risks.” And one of the PSFs for problem management is “optimizing problem resolution and mitigation.”

ITIL 4 defines a PSF as:
“A complex functional component of a practice that is required for the practice to fulfil its purpose.”

And, for each ITIL 4 practice, the relevant practice guide maps the key metrics, or KPIs, to the practice’s PSFs.

Turning CSFs into KPIs

Once CSFs have been agreed it’s time to define KPIs that indicate how well the organization is performing against these CSFs. There should only be a small number of KPIs for each CSF, otherwise the numbers become unmanageable.

Looking at the “Downtime of the service does not have a serious impact on the customer’s business process” CSF, example KPIs could be:

• A maximum of four events in any year where there’s a total loss of the service to all users
• The maximum downtime for any total service outage is 30 minutes

And remember, achieving these KPIs will not definitively prove that the CSF has been met, but it will help to indicate it.

Organizations should agree with the customer that this is what will be measured, and then report the KPIs to indicate how good the performance has been. But, in customer reviews, there’s a need to discuss the CSF, not the KPIs – with the customer discussion something like “Here is the KPI data, do you agree that downtime of the service has not had a serious impact on your business processes?” This way, organizations can focus on what’s important rather than on what’s being measured. Please read that last sentence again – it’s a very important point with KPIs and CSFs.

Why using best-practice KPIs can be dangerous

The ITIL v3/2011 books included many example KPIs, but in each section that listed KPIs it said:

“These KPIs should not be adopted without careful consideration. Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs and its particular circumstances.”

Let’s return to the example of FCR and think about whether this is a good KPI or not. Suppose that an organization just measures FCR and then reports it to show how the service desk is increasing the number of customer incidents and requests it closes during the initial phone call. This has to be good, right?

But then suppose that the organization succeeds with its self-service capability, with more and more employees self-managing their incidents and requests without the need for a phone call to the service desk. They might also use the automated password reset facility and knowledge articles to resolve common issues for themselves. This should lead to faster resolutions and happier customers but, as more of the simple incidents and requests move away from the service desk, the agents will have a higher proportion of difficult incidents to deal with. Hence, it will be harder to fix issues at first-contact and the FCR level will get worse and might even become irrelevant. Hence FCR might be a good KPI for some organizations, but it might be completely inappropriate for others. And, more specifically, using FCR to benchmark either over time or externally will be inappropriate as the incident and request mix changes over time.

So, when your organization is defining KPIs it really does need to think about: its level of maturity; its customers; and its goals, objectives, and CSFs. It’s also important to choose a small number of KPIs that will help it to indicate how well it’s doing versus the CSFs. You will also need to regularly review your KPIs to ensure they are still appropriate in light of stakeholder and other changes.

When did you last review the KPIs you use to manage your IT service desk? Maybe it’s time to think about them again.