The ITSM breakthrough was always just two small steps away

This White Paper explains in detail why the ITIL status quo endured for decades despite all the signs pointing to support's process needing improvement. The full background and all key facts are covered in the 1-hour SOFF Foundation Course.

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 largely unrecognised facts as explained in this White Paper which should be read after an understanding of AP has been gained.

Introduction

Ever since ITIL's inception, methodology to improve its process fundamentals has remained absent. With no alternative, the fundamentals quickly became the functionality of every IT Service Management (ITSM) software tool, and as time went by, ITIL's best practice stature grew stronger, obscuring shortcomings intrinsic of fundamental processes from being identified. For this reason, IT's processes have remained basic, locked-in through ITSM tools and thereby deeply embedded in the worldwide status quo.

For aspects of service management that do not have many operational requirements, a basic process is ok. IT support is the clear exception though. IT support is complex. A basic process cannot handle complexity. IT support always had a big problem, and thanks to the combination of factors, it has simply been tolerated, with the fundamental root cause remaining obscured and unrecognised.

General consequences of "the ITIL gap"

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

In being focused on the wrong thing - tickets, not "the timely activity that's required for attentive service" - IT service management's foundation has been without 12 vital capabilities. Every IT organisation has endured the consequences - frequently slow and failed support outcomes, unmanaged backlog, many chased tickets, service metrics that could not be weaker, and reputational harm - without realising that it does not need to be that way.

The cost to business in terms of employee lost work time over the decades, is immeasurable.

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

Barriers that made Activity Prioritisation elusive

1: ITIL dominance

Firmly embedded in the status quo, ITIL's processes have remained largely unchanged for decades. Almost every organisation uses an ITSM tool, so almost every organisation still uses the same Incident and Request Management fundamentals that it always has, making the processes deeply ingrained in how IT organisations "do" support.

With such pedigree, even the most obvious of support's many operational issues are overlooked, assumed to be unavoidable because what everyone regards as "best practice" is in use:

For the 25 - 30% of support needs that are not met straight-away, unguided progression maximises how often tickets reach their completion target / SLA deadline - a timeframe that in most organisations is excessive but still not met well.

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 service customer is ignored.

When properly considered in this light, it's hard not to conclude that ITIL's ticket-focused approach couldn't be less adequate. That its process must be incomplete, or even, as is the case, fundamentally defective.

Yet, it has endured for decades without "the ITIL gap" being identified.

What is considered to be best practice is not questioned, especially when it is "baked-in" to all software tools, but it's not just embedded acceptance of ITIL that shielded the process gap from being identified.

One of the 21 common operational issues that are identified by the Focus Framework shield it too. ITIL's ticket-focused metrics, primarily the ticket completion SLA ("Resolution 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 largely meaningless.

It is a realisation that points to the process being incomplete or fundamentally flawed. When metrics that measure the performance of a process are of limited use, and especially if they are statistically invalid due to inaccuracy, which is the case, the process itself must be at fault. Yet still, even with the rise of support service improvement through XM, dominance of the ITIL process still causes it to not be identified as being the root cause of weak support.

Instead, XM-led improvement initiatives target better focus from teams in an attempt to overcome the pitfalls intrinsic of how support operates, to overcome unrecognised process gaps. A nurtured approach to improvement when it should be process-led instead.

Despite two conflicting facts - that IT support is a complex operational arena but its process is basic fundamentals - 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 handled well, requisite support activity must be handled well. That support activity must always be timely. That support's process must be focused on activity, not tickets.

It's a great example of an accepted norm blind-siding what in hindsight seems so obvious. Speak to anyone who doesn't understand IT support - people who haven't ever worked in it - and you will often receive a surprised response of "but surely it must be done that way?", or even the assertion that it is done that way, but in fact, it's not.

2: The second barrier that made AP elusive: 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 ago.

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 the need for good status management, a third reason for AP remaining elusive is that any ticket situations that an organisation recognises do exist, without conception of status-based prioritisation or awareness of AP, it is not realised that all tickets should always have a corresponding current meaningful status, and so that a full set of lifecycle statuses must be added to a service tool.

Only when a good and complete set of "meaningful" statuses have been added does consistent status management become possible and only then does status management become compelling for the benefits that result. Only then is it realised that a breakthrough process can and should be 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 ticket situations that an organisation recognises. Ordinarily, though, there is no reason to identify them all - to identify every ticket status that can arise - 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 statuses are essential to cover all of the situations - the good set required for consistent status management and its AP process to be formed. There are over three dozen AP statuses in total, each reflecting a ticket situation that can arise; designating the full set that's appropriate for an individual organisation results in support being as in-touch and timely as can be.

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 until AP is recognised as being "true" best practice to supersede a legacy process that is in fact not often fit for purpose.

Sub-text note: ITIL's ticket-focused process is adequate and works well in the most straight-forward of support environments like hardware breakfix and simple question / answer CRM.

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