Burn Down the Backlog

Modern IT services are complex with multiple technology tiers, such as network, database, virtualization, and application. With each tier being supported by it’s own group of skilled specialists.

When a Service Desk acts as the single point of contact for all end user requests the workload on a given day is broad ranging – based on new Service rollouts, significant changes in service functionality or unplanned outages. Complex incidents require …

backlog_COVER

Please Note: Some content may reference images that are only available in the PDF version of the white paper, which free to download above.

 MANAGING THE BACKLOG

Situation:

Modern IT services are complex with multiple technology tiers, such as network, database, virtualization, and application. With each tier being supported by it’s own group of skilled specialists.

When a Service Desk acts as the single point of contact for all end user requests the workload on a given day is broad ranging – based on new Service rollouts, significant changes in service functionality or unplanned outages. Complex incidents require support from various specialists to restore service on critical applications.

But these specialists also have change and project commitments that may conflict with support for unplanned outages. When combined with staffing variability, for sickness and vacation, work invariably builds up.

Solution:

Effective management of backlog requires visibility of the history of open tickets, which cannot be reported using a simple database query. In addition to historical backlog, managers need to understand the reason for changes. Understanding changes in incoming ticket rate, difficulty of tickets, and availability of skilled staff is essential information to make decisions.

Analytics provides the insights on historical data that traditional reporting cannot by storing regular snapshots. The ability to track data sets over time and analyze multiple variables, enabling managers to evaluate options and select appropriate next steps.

Understanding the benefits of the solution:

The goal for burning down backlog is normally straightforward: a target reduction in open tickets by a specific future date.

Getting the team onboard with the approach needs explicit communication. Two reasons for reducing backlog are that it generates additional work when customers request status updates and hierarchical escalation. And secondly, improving Service delivery by shortening fulfillment time and reducing variance. Typically customers decide that it needs to be addressed, based on customer satisfaction or direct feedback.

Measuring the ROI on an ongoing basis requires specific metrics, which may include:

• Request backlog
• SLA achievement
• Customer satisfaction

BEST PRACTICE APPROACH

1. The first step is to understand the backlog.
First understand the process and how well it’s performing. How much work is being requested and how much is being completed – and how much is still awaiting fulfillment.

Key analysis: Backlog aging

Number of tickets not closed after 2, 5, 10 and 30 days (#). This analysis breaks down the open tickets based on how long they have been open. Incidents not closed within a couple of days commonly drive customer dissatisfaction.

This metric highlights how backlog is distributed. Reasons may include change in capacity due to vacation or illness, an increase in work difficulty due to a recent release (such as an SAP upgrade), or introduction of a new unfamiliar technology (such as Bring Your Own Device).

Key analysis: Work Backlog

Number of Incidents and Requests open at the end of a period (#). The change in backlog provides an indication of the ability of a team to keep up with demand.

To understand why the backlog is changing, drill down by assigned group to see which groups and individuals are under the most pressure. Check the rate of new tickets by customer group, assigned group and category for any indication of activity hotspots. Also check the rate of closed tickets by assigned group for any indication of declining performance.

2. The next step is to characterize the backlog.

It’s critical to remember that there is a customer behind each request. Understanding who the work is for, how urgent it is, and how long the customer has been waiting is the first step to getting a handle on the various types of backlog. Correctly characterized requests and incidents should be handled differently – with distinct timelines based on priority and urgency.

Key analysis: Untouched dormant backlog

Number of open tickets with last update more than X days (#). Incidents that haven’t been
updated in the last 5 days and requests that haven’t been updated in the last 30 days are probably dormant unless waiting on a customer or vendor response.

A significant number of tickets waiting for vendor response will skew the average resolution time. Consider a process change to close the incident and open a related problem.

Key analysis: Dormant ticket priority

Number of dormant tickets by priority (#).
Analyzing by priority highlights the proportion of dormant tickets that were critical or high when originally submitted. Any significant quantity of critical or high dormant tickets may be an indication of another problem, for example ticket priority not being leveled by the Service Desk or an underperforming vendor.

3. Finally, decide what action to take on the backlog.

Understand Your Customer

Analysis has highlighted which groups and applications contribute the most to backlog. Analyze deskside visits to really understand why there are so many requests. Look for underlying issues which can be addressed either in Support or with additional Customer training that would reduce future request volume. Aside from productivity tools (PC, laptop and mobile device), business applications typically have the highest ticket volumes – but build backlog because of technical complexity.

There are a number of options for reducing the current backlog, using the data collected above to make appropriate selections.

Escalate Critical and High Requests

For requests submitted as Critical and High, call the Customer to determine whether it is still an important request and also get any additional information required to expedite it. For Incidents, analysts should call at least once each day for 3 days to make contact, and the incident should be considered dormant if no contact is possible.

Close Dormant Requests

After discussing with the Customer, close requests older that are dormant. Agree with the Customer what a reasonable definition of dormant, and then evaluate how many are re-opened to adjust the definition.

Manage Expectations

It’s recommended that all requests are given an expected date. This will reduce the number of calls asking for updates, and should limit calls to discussions about relative priority of requests.

Drive Self Service Adoption

Make self service more attractive and more efficient to encourage end users to resolve simple issues or submit clean requests using self service. Providing the right information on top issues, and quickly escalating those known to need agent assistance will provide higher service while reducing the phone based traffic. See the white paper “Self Service Reigns Supreme”.

Eliminate Recurring Incidents

For requests that were closed with a temporary workaround, implement Problem Management to perform Root Cause Analysis. Prioritize changes
that address any underlying weaknesses to reduce future ticket volume, or use automation to mitigate the manual effort associated with the temporary workaround (example: server reboots). See the white paper “Eliminate recurring incidents”.