Is There a Better Best Practice for IT?

An argument is made for a new way to organize your IT service and support teams around activity prioritization. This […]

Category: Featured Article

An argument is made for a new way to organize your IT service and support teams around activity prioritization.

This is the fourth article in a series on twenty high-performance principles for IT support that can be embedded through ITSM tool-based processes or, alternatively, can be nurtured instead.

Here are six ideas that have been touched upon in the series 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 silos 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.

We tend to accept the substance of best practice frameworks and software tools as being what is needed to work well, but neither can be overly prescriptive in what they offer. As such, in my opinion, they are unlikely to be true best practices.

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 of this for IT support is busy teams focusing on new tickets to the exclusion of older ones. If slow service then results in a chase that’s ignored because there’s no chase management process, inevitable frustration equals bad 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 even more so is an advanced approach to prioritization for teams to follow

I’d bet my bottom dollar that if you analyze your aging tickets, process will be the only cause of progression stalling for some teams. And process, or more specifically, prioritization, would be the fix.

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, and I think it should be called IT support service management (ITSSM). Along with this, there should be a detailed but universally applicable framework and underlying methodology made available to fill historic gaps. Unless this happens, support practices will remain stifled.

Here are my other arguments for setting ITSSM apart:

  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, at least until ITIL 4, as merely a function of ITSM. Agreed, IT support is primarily a transactional endeavor, but the service aspect is also 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.

For support to be done well, prioritization is key. Activity must be timely at every progression point across every ticket’s lifecycle.

An advanced approach to prioritization centers on the use of ticket lifecycle statuses. The real ticket lifecycle is quite specific and extensive, extending well beyond what we are provided with “out-of-the-box” in ITSM tools. Once a full set of statuses is established, progression threshold periods can be specified for each status 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.

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 you are wondering whether there’s an imperative to adopt it for PPP, do the math.

Recent Posts

Quick Links

Refund Reason