The ITSM breakthrough was always just two small steps away

This article explains the ITIL status quo, and Flow Management's place, in detail. For the background and key facts, please first read "ITIL Success" first.

IT Support could never function well.

As a "fix-all", Activity Prioritisation reverses the status quo. Better still, AP adoption requires just two small and natural steps that any organisation can take. So, why is it new only now?

The complete answer covers more largely unrecognised facts. This white paper article also expands on why Experience Management is overly challenged without IT support's process being fundamentally improved.

Introduction

For decades, methodology to improve on the ITIL fundamentals remained absent, leaving ITIL's processes to become firmly established as the universal criteria for ITSM tool functionality, consolidating the framework's global stature and deeply embedding its basic processes, along with their shortcomings, in the worldwide status quo.

But IT support is complex. A basic process cannot handle complexity. Standard practice always had a big gap, and support a big problem.

General consequences of the ITIL gap

The big gap in ITIL's processes for Incident and Request Management has had far reaching consequences spanning the decades.

In being focused on the wrong thing - tickets, not activity - IT service management's foundation has been without 12 vital capabilities. Every IT organisation has endured the consequences - frequently weak support outcomes, lost work time, and service metrics that could not be weaker.

Over the decades, business cost is immeasurable.

Customer Relationship Management (CRM) has the same mistargeted focus - the same process gap. In external customer service environments that are complex, "Case-focus" means line-of-business customer needs are sometimes not attentively met. The implications here are more severe - lost customers and reputational harm. For many organisations, CRM has more to gain from adopting Flow Management.

Barriers that made Activity Prioritisation elusive

1: ITIL dominance

Embedded in the status quo, ITIL's processes have remained largely unchanged for decades. Every larger organisation still uses the same Incident and Request Management fundamentals that it always has, making the processes ingrained in how IT organisations "do" support.

With such pedigree, even support's most obvious issues that overarch some of the 21 identified by the Focus Framework, are overlooked:

For the 30% of support needs that are not met straight-away, unguided progression maximises how often tickets reach their completion target / SLA deadline.
Teams naturally focus effort on new tickets ahead of SLA breach warnings, so breaches happen often.
After a breach, it is "too late". There is nothing in the ITIL process to encourage onward activity, so a ticket that breaches its SLA is prone to abandonment.
Placing a ticket "on-hold" is usually SLA breach prevention. Widely misused for this reason and providing unlimited "breathing space", this is a second cause of ticket abandonment, or at least inappropriate long delays in which the customer is ignored.

When properly considered in this light, it's hard not to conclude that ITIL's ticket-focused approach could barely be less adequate.

Yet support's process endured for decades without the ITIL gap being identified.

Best practice is not questioned, especially when it is "baked-in" to all software tools, but it's not just acceptance of ITIL that shielded the process gap. One of the 21 issues - ITIL metrics - shield it too. Ticket-focused metrics, primarily the ticket SLA, provide the false impression of acceptable service quality.

Thankfully, the Experience Management (XM) movement is bringing attention to the fact that support's traditional metrics are "watermelon" and meaningless.

It is a realisation that points to the measured process being weak and inadequate. Yet still, even with the rise of support service improvement through XM, dominance of the ITIL process means it is not identified as being the root cause of weak support.

Instead, XM-led improvement initiatives target better focus from teams to mitigate the above-mentioned process pitfalls amongst others - a nurtured approach to improvement.

Despite two conflicting facts - that IT support is a complex operational arena but its process is a basic minimum requirement - acceptance of ITIL rules-out the process ever being reviewed as part of an improvement plan...

ITIL dominance blocks the realisation that for tickets to be managed well, necessary support activity must be managed well; that support's process should be activity-focused, not ticket-focused.

It's a great example of an accepted norm blind-siding what in hindsight might seem obvious.

2: ITIL does not recognise the importance of good status management

ITIL guidance does refer to carefully thought-out additional ticket statuses being useful, but goes no further than this. The framework has no mention of developing a full set for consistent status management. If it did, activity-focused IT support would no doubt have arisen a long time before Opimise introduced it.

This is the underlying reason for Activity Prioritisation being new only now.

In likelihood, when the Incident Management process became what it is today (ITIL v2, 2001), no one was at that point of realisation, of how advantageous good status management can be. Ensuing ITIL dominance prevented realisation since.

3: Organisations add custom statuses piecemeal with no intention of a process

With ITIL not drawing on good status management, a third reason is that for support situations that an organisation might recognise, without conception of a status-based approach or awareness of AP, it will not be realised that all should have a corresponding status added to a service tool.

Only when a good set of "meaningful" statuses have been added does consistent status management become possible. Then, doing so becomes compelling for the benefits that result, and so on to a breakthrough process being formed.

4: The true nature of support's complexity is far from understood

A good or full set of statuses typically extents well beyond the range of support situations that an organisation recognises. Ordinarily, though, there is no reason to identify them all - every status - lessening the likelihood of an activity-based process being realised.

When AP was developed by Opimise, its status-set was identified over a period of years by directly observing the nature of support in several organisations. Not including "new" tickets and SLA breaches, AP covers 21 ticket lifecycle situations that arise in all IT support organisations. 12 are essential and global - the good set required for AP to work well. There are over three dozen in total; designating the full set that's appropriate for an individual organisation results in support being as timely as possible.

These four factors mean that while IT professionals generally do recognise that additional ticket statuses should be beneficial (most IT organisations have added some), and ITIL recognises it too, AP's criteria of having a complete status-set that enables consistent status management for a system of activity prioritisation, is not reached.

The barriers are now removed

The Focus Framework's body of knowledge (BoK) is selectively shared with organisations interested in the approach, to achieve five Opimise goals:

The many causes of weak support - common operational issues in the ticket-focused approach - to be recognised.
Activity Prioritisation to become standard practice by being made available in ITSM tools, integrated with ITIL's Incident, Request, and Service Level Management processes.
Contribution Recognition basics to become standard practice.
Flow Management (SOFF) to be a popular accreditation for organisations.
The Focus Framework's Support Lifecycle Management practice to be added to ITIL guidance - for ITIL to recognise the importance of support activity guided through consistent status management.

Below is explanation of the top nine unmanaged support situations. Most will be familiar, but precisely why they are problematic and needing to be managed by AP, perhaps not.

Experience Management needs Flow Management

Flow Management is new for 2025. Experience Management is new in IT too. Like FM, XM raises awareness of weak support outcomes and targets improvements, so for comparison, it is worthwhile to understand the sort of improvement initiatives that are being derived from the XM lead, and why instead, Flow Management needs to lead the way.

Firstly, to help teams step-up to the tall-order of somehow overcoming ITIL process shortcomings / pitfalls without process improvement, strong procedural guidance is needed.

A team's Standard Operating Procedure (SOP) manual consolidates guidance and should cover all policies, processes, practices, and general support procedures. Ideally, it would be developed with alignment to the Focus Framework's twenty good practice principles.

Other than SOP, a second common initiative is to disallow placing tickets “on-hold”, tackling one of the main operational issues head-on. It is an initiative that is often advised by consultants.

On the face of it, especially for organisations that use a ticket SLA, removing on-hold does seem sensible. Teams can no longer rely on it for "breathing space" to the detriment of attentiveness / experience and unmanaged backlog, and on-hold's most harmful negative affect might be softened, of tickets that are waiting on information from a service customer not having the information chased when not received (unmanaged situation # 2 in the above infographic).

On balance though, prohibiting on-hold is not a good thing to do.

Many support situations are intrinsically on-hold, and moreover, they need to be on-hold if a ticket SLA is to have validity, and if closing tickets without due diligence, to avoid SLA breaches, is to be avoided. After-all, these are the reasons for it having always been an important feature in ITSM tools.

For example, if needing to monitor an Incident after initial work to fix it, the ticket SLA should not breach during the monitoring period. Nor should the ticket be closed without monitoring. If on-hold is not used, one or the other of these undesirable outcomes will almost certainly happen.

To make support’s process even more basic is harmful, and is likely to add stress to the work of support teams. It is an initiative in the wrong direction.

Instead, on-hold, and tickets generally, must be closely managed.

The world's support process couldn't be less adequate though, making achievement of the objectives nearly impossible and use of on-hold a universal dilemma...

"If wanting to properly measure and manage support, you must use on-hold, but ordinarily you should not."

In any business context, like meaningless metrics, a paradox is always a sign that there's something substantially wrong, that the way of working - the process - needs to be improved. Indeed, support's other paradox surrounds the ticket SLA metric.

"If wanting to measure the performance of IT support, you must use a ticket SLA, but due to its inaccuracy and meaningless nature, ordinarily you should not."

Without over-staffing, nurture alone cannot get anywhere close to tickets, including those that are on-hold, being closely managed, even with the benefit of a good SOP manual.

To get a bit closer, an organisation might invest in managerial resource and effort to oversee ticket management across teams, to help teammates "step-up" to the objective of mitigating process shortcomings.

Some do commit to doing this, but it is micromanagement, to be avoided. Additionally, intervention to encourage faster ticket completion is known to have undesirable consequences in which service delivery is worsened. Premature ticket closure - service failure - replaces incidence of tickets taking too long.

Quite clearly, unlike other ITIL processes, Incident and Request Management cannot be made fit for purpose. It is so inadequate that it necessitates micromanagement and causes "the dilemma of on-hold".

Where is XM with Flow Management?

Thankfully, systematic status management for Activity Prioritisation doesn't only produce attentive service from self-managing teams for good service experiences, amongst its many other transformations, it fixes the problems of on-hold and SLA invalidity too.

In any service tool, on-hold is configured by mapping it to ticket statuses. So, consistent status management naturally results in on-hold being used in a wholly consistent and appropriate way no matter the support situation, for absolute SLA accuracy.

Then by moving to standard AP (sAP), continual progression means that on-hold is also controlled. It can no longer be used for breathing space, adding timeliness and validity to an accurately measured ticket SLA that requires no data editing before presentation to a supported business.

"The classic IT watermelon metric becomes useful and green inside".

But stronger interest might be in FM's Progression SLA which, as AP grows in use across organisations, is set to become the ticket SLA's successor in terms of importance.

The Progression SLA is one of FM's primary Flow Metrics in which success in meeting support's primary purpose of always timely attentive service provision, is known.

Optionally, Flow Management automatically and continuously communicates "pinpoint" progression expectations. Any substantial delay beyond a customer's expectations negatively affects service experience, making Flow Metrics operational ("O") metrics that are also experience ("X") metrics, providing the ability to merge XLA with SLA. Furthermore, Flow Management's ability to control "progression breaches" is real-time experience management.

AP - Flow Management - is a fix-all. An incredibly rare thing.

Why not subscribe to the Service System blog written for HDI SupportWorld, to receive a key insight about IT support's struggles weekly...