Considering a New ITSM Tool? Remember the Stakeholders

I recently facilitated a meeting of the HDI Desktop Support Forum in Dallas, Texas. During a discussion about getting metrics reports, I asked two questions:

1. Are you getting the reports that you need?
2. Did you have a say in the choice of the tool?

The answers were almost unanimously “No and no.” Even worse, many desktop support managers and directors were not even asked to contribute requirements in advance of the RFP for selecting a tool.

The work of a desktop support group—deskside support if you prefer—can be distinguished from the desktop support work performed in the support center by remote control. Some organizations call it field support or local IT. Although the overall service provided by desktop support (resolving incidents and fulfilling requests) is similar to the support center, the reporting needs are different, and the tracking needs are different.

What’s Different?

Desktop support groups are typically considered escalation groups, or Level 2. Incidents that cannot be resolved at Level 1, requests or incidents that require a visit to the deskside, hardware replacement, imaging, etc., come to the desktop group. Often, desktop techs are required to travel; the HDI 2016 Technical Support Practices & Salary Report says that 70 percent of desktop support technicians travel to provide support. Thus, the calculations of time to repair/time to restore are more complicated. Most organizations do not have their ticket-tracking tools configured to provide a ticket status for “Traveling to/from site,” and fewer have a travel tracking tool that seamlessly connects to the ITSM tool or other ticket tracker.

70 percent of desktop support technicians travel to provide support.

Further, desktop support techs are often assigned to projects that require a percentage of their time, and little of that work gets tracked in the same tool the support center uses, because projects are most often tracked elsewhere.

Requirements Gathering

In the long, complicated process that is preparing an RFP for an expensive ITSM tool, how are these key stakeholders being overlooked? What organizational advantages are being missed because stakeholders aren’t being identified and consulted? Does it make sense to proceed with a choice of tools without having input from all the groups that will be using those tools?

Follow the Money

Desktop support is expensive. The average salary for a desktop support tech (in organizations that have one level of DST) is about $6,000 higher per year than the average for Level 1 support center analysts. (Data from HDI 2016 Technical Support Practices & Salary Report.) Factor in untracked or poorly tracked travel time and project time, and you can begin to see how quickly the budgets start to get “fuzzy.”

Related Reading: Focus on Developments in Desktop Support

Let’s take a quick example of how better tool choice would affect both desktop support and the support center, as well as the organization as a whole:

• A call (or email, or chat session) comes into the ABC Company’s support center about issue X.
• The issue cannot be resolved at Level 1, because L1 analysts are not permitted access to the remote control tool the company uses.
• Desktop support catches the ticket, attempts to resolve the issue via remote connection, but fails and dispatches a tech to the site to resolve the issue.

Without the proper tools and tool integration, it is difficult to determine the true costs of this incident. Without the ability to accurately track the time it took for the technician to get to the site and resolve the issue (and travel back), it is virtually impossible to determine the proper staffing level for the desktop support group. And so on.

If you don’t get all the stakeholders in the room to begin with, that shiny, expensive tool you are buying may only serve to frustrate other groups within IT, and make it difficult to get partners to work together effectively. Get everyone who should be involved working together on requirements.