ITIL & Support Flow Management: Key facts

Lesson 1 of the SOFF Foundation course. Note that shorter versions of this Key Article contain only half the facts.

For over three decades, ITIL's dominant best practice stature concealed four pivotal facts and that overall, it made a crucial oversight. ITIL missed something vital out - the process root cause of weak support.

Capabilities for Flow Management fill the gap, fixing timeliness, expectations management, performance, weak metrics, teamwork and more.

The Problem Caused by the Oversight

Most IT support professionaIs meet service targets well enough to satisfy IT standards, but a large proportion of recipients end-up dissatisfied. Fact is, ordinarily, IT's ability to meet needs and expectations is far worse than is known.

Worsening outcomes, recipients learn that if support is chased for a response to something urgent, the effort often goes unnoticed and unaddressed even if the Service Desk process seems good. Consequently, many recipients are inclined not to chase when necessary to do so, letting the support experience slip further still.

By practicing Experience Management (XM), a much clearer picture of the problem's extent is realised. Of tickets not completed at the initial response, over a third are felt to take too long, and a quarter turn bad*.

Detailed analysis of any organisation's ticket backlog confirms why this is the reality, but the cause is not so much in teams being busy. The cause is inadequate prioritisation of an inadequate process.

In ITIL standard practice, tickets are organised only by the initial response deadline, then, for those requiring further work, by ticket age and perceived priority, with the oldest tending to come last.

What is needed, though, is for work to be organised by the continuous activity that's required for attentive service. Formed from new guidance that ITIL missed out, Activity Prioritisation is a breakthrough that does precisely that.

Here's the Key Facts:

With its processes the basis of all ITSM tools, ITIL is firmly "baked-in" to the status quo, making its best practice stature powerful and unquestioned.

But ITIL is a framework, not a methodology.

Framework processes are minimum operational requirements - best practice at the most basic level.

A framework's processes must be built-upon to meet operational needs, but ITSM tools provide ITIL's largely "as is".

For most processes, that's ok, but not for IT support.

ITIL's minimum requirement for IT support is a ticket-focused approach that guides only new ticket responses - nothing afterwards except a deadline for completion. So that is the process found in all tools, used the world over.

Typically, over a quarter of support tickets are not completed at the initial response (30% according to MetricNet), requiring timely onward progression activity before completion is reached.

Effective communication with service customers is key, but with a process that prioritises only tickets, not progression activity, communication could not be weaker.

Note 1: Rather than simply "On-hold" and "In progress", meaningful conversational statuses are used in some organisations, but still, in standard practice without Activity Prioritisation, they do not rise to the top for prioritised attention.

Note 2: It is not enough for teammates to send an email and expect that the service customer will respond. Ticketed communication from IT is an ITSM tool (system) notification. Some recipients filter notifications out in their email software, or simply ignore them. Often, at least some phone or IM based reapproach is necessary.

Pivotal Fact 1: Absence of a way to identify, prioritise, and manage progression activity is a big shortcoming - a critical gap in support's process.

Pivotal Fact 2: Consistent status management brings focus to required activity, enabling timeliness for all ticket situations through Activity Prioritisation (AP). For most support organisations, it is a key aspect of support's minimum requirement, but it is absent in ITIL guidance. Absence in ITIL means absence in tools, forming a status quo in which support is inattentive because it is focused on the wrong thing.

ITIL's crucial oversight is absence of Consistent Status Management in its guidance

Other than "On-hold", just two ticket statuses are provided by ITIL and ITSM tools for the ticket-focused approach - "New" and "In progress".

Many ticket situations sit under the broad scope of "In progress". Each has its own distinct "meaningful status" to identify what needs to happen next, and an appropriate timeframe for when progression should happen. For example, after an email is sent, a status for follow-up by phone or IM might be "Reattempt contact", and IT governance might decide that the appropriate timeframe is two-hours from when the status is set. For when a customer replies, the status might be "Attention", with teams expected to review tickets that change to this status within 90-minutes.

But in ITIL standard practice with just two generic statuses and basic ticket-focused prioritisation, what needs to happen next is not only unidentified, the required activity continues to drop down towards the bottom of ticket lists where it naturally receives the least attention, especially when "On-hold", leaving service customers frequently ignored. Other than causing weak communication where conversation threads suffer long delays or inertia, it is why ticket backlog is badly managed.

Unidentified ticket progression activity continues to drop to the bottom of ticket lists because with support organised by ticket age, new tickets are usually at the top.

All kinds of ticketed communication are affected.

Compounding the ITIL process gap, as a framework, supporting processes are also absent, including a way to handle chased progression which frequently arises due to untimeliness inherent of the misfocused approach. Most chases are nothing more than buried ticket updates - one kind of ticketed communication that's prone to failure. The result is often "multi-chases" that despite being the worst of support outcomes, go unrecognised.

In total, 21 ticket situations - support statuses - are left unmanaged in every IT organisation, all causing inappropriate delays and ticket inertia, including:

Those for collaboration and teamwork;
Those for follow-ups like Incident monitoring.

Support appointments, including where coordinated contact is necessary because a customer's availability is limited;

Supplier provided service.

Additionally, "SLA Breach Prevention" is not guided in the ITIL process.
Overall, due to ITIL having formed IT support's process, support is highly disorganised.

Pivotal Fact 3: The critical oversight - that is, absence of consistent status management in ITIL's guidance - has been harmful for another reason that's even more fundamental than inadequate prioritisation.

The accuracy and validity of support's primary metric, the ticket resolution SLA, necessitates consistently appropriate exclusion of "on-hold" periods. Ticket on-hold is mapped to statuses, so controlled on-hold is possible only through consistent status management, plus its use for Activity Prioritisation to ensure on-hold tickets do not stagnate while being protected from breaching their SLA target.

Without it, "uncontrolled on-hold", or an operational decision to disable on-hold functionality because of the issues it causes, means an SLA dataset is always so inaccurate that even with extensive ticket-by-ticket review and dataset editing, SLA reports might still be statistically invalid. It's a stark fact. Due to ITIL's oversight, ordinarily, support's primary measure for the performance of its processes is invalid and should not be used.

"The problem of on-hold" and use of a ticket SLA are both an IT support "catch-22" - both unavoidable in use of the ITIL process alone.

A process catch-22 is always a sign that something is wrong with the process, and that operational difficulties exist.

The Solution and Way Forward

Flow Management's base capability, Activity Prioritisation, produces time-based metrics that are wholly accurate and meaningful by default, bringing absolute validity to a ticket SLA for the first time, removing the need for data review and editing.

Standard AP fixes the ticket SLA, but mainly it fixes timeliness across all ticket situations so that business lost work time is minimised, SLA breaches are minimised, and precise, dynamic timeframe expectations can be shared.

In AP, support work is organised by when progression is scheduled to happen, not by ticket age. New ticket responses are merged with the timely scheduled progression of all older tickets...

Fluid ticket-based conversations, handled chases, and good expectations management reverses IT's reputation for weak communication.

But without Flow Management, this is the status-quo:

ITIL's processes for Incident and Request Management are absolutely minimal - too minimal - devoid of capability to handle support's complexity or to expose where weak support is experienced.

Teams are left unguided - misfocused and unfocused, unable to fulfil their purpose of always timely, attentive service provision.

Pivotal Fact 4: Inextricably, without adding Support Flow Management, every ITSM tool, and almost every support service that relies on them worldwide, is not fit for purpose. The reputation of IT support is harmed for little other reason.

ITIL's embedded stature shields recognition of this pivotal fact. The fact that support's process is too basic is not realised. Instead of looking to improve the process, even if practicing Experience Management to expose and address the extent of weak support outcomes, weak support is considered to be largely unavoidable because ITIL best practice is in use.

Global harm in lost work time, customer frustration, and IT's reputation, is immeasurable.

The breakthrough is simply to establish at least AP's complete set of twelve meaningful statuses. Only then does consistent status management become possible, for all the many benefits that then arise.

The imperative:

Standard Activity Prioritisation (sAP) is a rare kind of process. Despite being incredibly simple, it guides effectiveness with no need for governance and management.

In use of sAP with "pinpoint" expectations management, when communicated progression timeframes are not met, service experience dips. This knowledge is captured in sAP Flow Metrics.

Flow Metrics measure the attentiveness of support - the service experience - in real-time and retrospectively.

For an Experience Level Agreement (XLA) that is used by some Managed Service Providers and other operationally mature IT organisations, key Flow Metrics are:

Progression SLA, for example, "Attentiveness: For tickets not completed at the first response, 80% of scheduled ticket progression will happen on time; 97% within 4-hours of progression thresholds breaching";

Progression Backlog, for example "Progression Backlog will not exceed 5% of open tickets".

By controlling progression backlog, which is strengthened through advanced AP, expectations are met as well as possible and unmanaged ticket backlog cannot build.

ITIL is no longer process oriented. It has moved even further from being suitable as the benchmark for ITSM tool functionality and IT support's way of working.

The Flow Management methodology has an entry point for every organisation. Any ITSM tool becomes nearly fit for purpose simply by consistent status management becoming an organisation's way of working, and by switching from unhelpful ticket lists to an organised basic AP Progression Dashboard.
Basic AP makes the ITIL process much more successful by bringing procedural focus to SLA Breach Prevention and conversation threads.

sAP has several advantages over basic AP. Workload is presented through a single ticket list which is the way teams have always worked, adding to its simplicity that makes it easier than any other approach, but all required activity is sequenced with ideal timing:

Most people in IT support realise that status management should be advantageous. Some non-standard statuses are commonly added to ITSM tools. Alignment with the Focus Framework to enable the breakthrough - consistent status management in which it becomes advantageous - is a natural and popular enhancement.

Advanced AP and Perfect Prioritisation combine sAP with a Progression Dashboard and optionally, advanced Flow Management capabilities, to reach a target level of operational maturity and if desired, true optimisation in which ITIL's processes are made as successful as possible.

AP's counterpart, Contribution Recognition, enables advanced AP and Perfect Prioritisation because without effort being recognised, there is no impetus to help-out across ticket queue silos.

Contribution Recognition is based on Flow Management's Activity Flow Metrics which are the all-inclusive, accurate and fair representation of a teammate's contribution at work. The Contribution Recognition standard includes mechanisms to ensure accurate fair representation. Gallup Inc. research shows that when teammates are given performance information of this quality, engagement nearly trebles.

Activity Prioritisation of any type enables Portal Purposing for the Digital Channel Service Desk. As a methodology and standard for modern people-provided support, the many vital but generally unrecognised reasons for moving away from old-fashioned call-centre reliance form a core aspect of the Focus Framework, alongside the solution that transforms a service portal into the number 1 choice for all support needs.

More insight into the ITIL status quo and why capabilities for Flow Management remained absent for so long, can be read in this White Paper.

Next: What Flow Management is

(lesson 3 in the SOFF Foundation course)

* Source: HappySignals Global IT Experience Benchmark Report.

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