Written originally for HDI's SupportWorld (ThinkHDI.com) and complementing our micro-learning course, this series of articles discusses the two alternative approaches that can be taken - nurtured principles v. systemised success through the TOFT service system...


Bite-sized learning: Subscribe to receive the series one-by-one

4: A Better Best Practice for IT Support

6 unspoken facts

Six “quiet” facts have been touched upon so far:


1. Standard practice processes, as explained in ITIL and provided for use by ITSM tool vendors, are inadequate to handle IT support’s complexity.


2. It is up to individual organizations to fill standard practice gaps, so that all operational needs can be met.


3. Failing that, nearly two dozen operational issues remain. Most harm timeliness and reliability.


4. Adding to the challenge, perfect work siloes are the fabric of standard practice. To counter this major constraint, better methods of collaboration and teamwork are needed.


5. To be highly attentive, teams must focus on the right thing at the right time. This necessitates advanced prioritization - activity prioritization - which is the main thing that’s missing from standard practice.


6. To get started with improvement, standard progression point prioritization (PPP) is a simple enhancement that can make standard practice timelier and more reliable for all teams.


So, this is the status quo, but why?

We tend to accept the substance of best practice frameworks, and software tools, as being what is needed to work well, not appreciating that neither can be overly prescriptive in what they offer, so are unlikely to be true best practice.


It took me twenty years of “observing directly” and wanting to enable IT team capability, to realize that there are so many issues, and thankfully, a way to remove them all.


Harmful behavior is the result

When relying on the high-level frame of best practice, guidance might be inadequate or missing when operational complexities arise, so harmful behaviors can be expected.


The prime example for IT support is busy teams focusing on new tickets to the exclusion of older ones, because ticket-based prioritization does not guide mid-lifecycle activity, particularly when tickets are on-hold. If slow service then results in a chase that’s ignored because there’s no chase management process, inevitable frustration equals bad experience.


From harm to good experience

It is good to see that ITIL now includes that support staff should empathize with a requester’s need – to be attentive, in other words. But what is needed much more so is an advanced approach to prioritization for teams to follow.


I’d bet my bottom dollar that if you analyze your ageing tickets, for some teams, process will be the only cause of progression stalling, and process, or more specifically, prioritization, would be the fix. Not empathy, as important as empathy is.


Time for a refresh?

IT support best practice processes have not changed for decades. If support is to be modernized and the issues removed, more attention must be given to it. So, should support be recognized as a distinct and specialized division of ITSM?


I certainly think so, as IT support service management (ITSSM), and a detailed but universally applicable framework and underlying methodology made available to fill historic gaps. Unless this happens, support practices will remain stifled.


Other reasons for setting it apart are:


1. ITSM, by proxy primarily of ITIL, is about the broad management of IT system services.


2. IT support is also a type of service, but ITIL classes it as “service support” and until ITIL 4, as merely a function of ITSM. Agreed, it is primarily a transactional endeavor, but the service aspect is very important. Reliable service is possible only through effective processes.


3. It is the overarching thing that most IT professionals do.


4. It has the broadest influence on IT service customer experience.


Missing processes and practices that come together to form a whole new way of working, include activity prioritization (aka PPP), true contribution recognition, asynchronous collaboration, service desk reinvolvement and learning, expectations management, flow management, operational problem management, quality and security protection, and progression automation. Plus, user escalation (chase) management, but with advanced activity prioritization, chases might be received only when a team is understaffed.


Three types of IT service

I don’t think many people would disagree that support is also a type of service run by an IT organization. Dare I say it, another type of IT service. There is a third type as well though – business services. IT system and support services both fit neatly under IT’s business service.


If you agree with this, you will probably agree that there should not be a single definition of what an IT service is.


The definition of an IT support service

My pitch is:

“The provision of information or assistance that meets a person’s needs as quickly and easily, or as conveniently, as possible”.


The support service lifecycle

Centered on system services, in ITIL 3, the service lifecycle came to be.

In operation, a support service has a lifecycle too - the service ticket lifecycle – but not as most of us know it.


What is the real ticket lifecycle?

Formed of statuses, the real ticket lifecycle is quite specific and extensive, not simply open, in-progress, on-hold, and SLA breach, as we might be led to believe. In fact, what we are given in tools are lifecycle states, not statuses.


As important as it is, enabling the definition of support to be brought to life, neither a framework nor a methodology includes it. So, I’d be quite sure that almost no one knows what it is.


Transform support

The main realization that I’m hoping to get across is that for support to be done well, activity must be timely at every progression point across every ticket’s lifecycle.


The best way to achieve it is to specify a progression threshold period for each progression point, being the governed maximum lead-time before onwards progression is expected after a status has been set.

When teams simply change a ticket’s status on each touch to reflect what needs to happen next, progression threshold timestamps are continually adjusted according to changing ticket scenarios, so that all required support activity is sequenced in the most appropriate way possible, corresponding precisely with how an IT organization wishes to deliver support.

By working through tickets in this order, the question of “what next” becomes a thing of the past. No ticket gets forgotten, and managers can oversee progression breaches “by exception”. Other benefits include high performing Resolution SLA’s that are measured with absolute accuracy, plus potential for dynamic expectations management.


From one organization to the next, there is extensive commonality in the spread of “meaningful” statuses that make up the real ticket lifecycle, making sense of hundreds or thousands of open tickets.

Your teams probably already use statuses, so it’s just another small adjustment. Importantly though, not all ITSM tools can properly support it, so if considering a switch, watch out.


The future of service experience

Support is the main “experience arena” for IT. Timeliness influences support service experience the most. Alongside adequate staffing, effective prioritization makes timeliness happen. The real ticket lifecycle enables effective prioritization. So, if wondering whether there’s an imperative to adopt it for PPP, do the math.

Written by:

David Stewart

SHARE

Opimise on LinkedIn

Original article was published for the Help Desk Institute (ThinkHDI.com)