Why Your Service Desk Shouldn't Implement Your ITSM Platform

Posted by Amanda Fairbrother Casteel on Sep 13, 2016 3:41:00 PM

In Service Desk, ITSM Tools

Avoid the drama of competing priorities. Here's why it's a better bet to take this task off your Service Desk's plate.
Every environment in which I’ve worked over the past twelve years has put the Service Desk (or Service Desk vendor) in charge of implementing its ITSM tool – including subsequent maintenance, ongoing development, and even driving the tool selection process itself.

It seems like a smart move to approach the project in this way, no? The Service Desk will be using the tool the most, so tasking anyone else with making decisions around it seems counterintuitive.

It’s not. Here’s why:

It’s a rare thing these days to deal strictly with an internal IT shop wherein everyone works for the same company. Instead, we often work in complex, multi-vendor, mixed-team environments with both internal and external customers. These multi-vendor environments, specifically within the government sector, are where you’ll run into issues with a Service Desk-led tool implementation. Let’s say you have the following structure, or something like it, in place:

    • Vendor A: Provides Service Desk support and system administration services
    • Vendor B: Provides network and cabling services
    • Vendor C: Provides system engineering and Change Management services
    • Vendor D: Provides hosted email services 
    • Internal IT Staff: Provide a mixture of all technical management services (in-house IT)

In this scenario, it seems sensible to put Vendor A in charge of the tool implementation initiative, as they will have the most internal knowledge around the state of your IT processes. This gets messy, however, as Vendor A’s focus is to meet Service Level Agreements (SLAs) as defined by their underpinning contract (UC). Since these UCs just so happen to be legally binding and directly effect whether or not they get paid, Vendor A necessarily has a vested interest in supporting the processes they use to accomplish those SLAs. It makes for a pretty decent setup for conflict of interest.

But let’s give Vendor A a little credit and say they’re a shining light of an organization that truly cares about your business and sincerely attempts to implement best practices for all vendors equally. While we’re grateful for their earnestness, they still won’t have the authority or oversight to get the other vendors involved. So, even with the best of intentions, Vendor A may well end up having to guess which processes or features are most valuable to the other vendors.

The fallout from this typically looks something like Vendors B & C growing to resent Vendor A for making them do additional work without the common understanding that it will be for everyone’s benefit in the long run. It’s an impossible task for Vendor A. And poor Vendor D, they will usually go overlooked since providing hosting services doesn’t guarantee them on-site presence. It’s no good.

Okay, new scenario.

Let’s say your Service Desk isn’t outsourced, but rather internal to your organization. Even in this case, it is difficult to task them with making decisions that will effect other areas of IT, as they aren’t likely to have visibility into IT’s strategic decisions. And, frankly, they may not even have the time to devote to managing the tool – especially if they are constantly fire-fighting, handling Incidents and Requests, etc. At best, you’re limiting their ability to expand the tool’s capabilities into other areas of the business. At worst, you’re placing yet another responsibility on an already extremely busy team and setting them up for failure.

So, who should own it?  While the Service Desk should definitely provide feedback and insight, the best approach and first step to any implementation should be to recruit a champion from leadership. Specifically, someone with visibility across the organization and all IT processes at a strategic level (say, the CIO). This person can more easily get additional leadership – and key stakeholders across the organization – excited about and contributing to the effort. This degree of buy-in and consultation is vital to the success of any implementation project, and it’s something the Service Desk simply cannot secure without help. Show me a failed ITSM tool implementation, and I’ll show you a project without a champion from high-level office (and with a very unhappy Service Desk).

Accept the counterintuitive. Finding someone in IT leadership – outside of the Service Desk - is the best approach for long-term success of your ITSM platform investment. You will be much happier with the result, and your Service Desk will thank you.



Looking for more Service Desk goodness?
Here's how to rebrand your Service Desk as a single point of contact?