6 Phrases You Shouldn’t Hear During an ITSM Tool Implementation

Imagine a speeding truck going 100 miles per hour. Now, imagine trying to replace the engine of this speeding truck without slowing down. No, I’m not leaking the plot for the next speed movie. I’m simply expressing how an ITSM tool implementation looks by drawing an analogy.

I’ve spent a good chunk of my career on ITSM tool implementations. (Brag alert: our project won the SDI Best Implementation of an ITSM Solution award two years in a row.) So, I can spot a bad tool implementation from a mile away.

To make it easy to detect, watch out for these six phrases. If you hear them on your project, you know that it’s time for an intervention.

Number 1: “When Does This Project End?”

Ouch. No. This is 2020. An ITSM tool implementation cannot be called a project. I can talk about why projects don’t work, but I think you should read Rob England’s post, Overcoming the dysfunctions of IT project management.

The biggest challenge with viewing the implementation as a project is that you assume it has an end date and you take your focus away. You’ll soon find yourself in a meeting room a year later asking “Aright, we need to reimplement the entire system because the tool didn’t work for us”

It’s obviously not the tool’s fault! Tool implementations are iterative in nature. They cannot start and end like a project. They need to be managed like a product.

Possible remedies:

• If anyone is walking around with the title of “project manager,” remove it immediately.
• Plan work in sprints, versus the rigid start and end date.
• Keep checking back with the stakeholder to see if you’re on the right track.

Tool implementations cannot start and end like a project. They need to be managed like a product.

Number 2: “Wait, Why Are We Starting Now? We Still Have 6 More Months Contract Pending.”

This statement is a clear signal that the key stakeholders are in denial. They are not fully bought into the idea that the old ITSM tool needs replacing. Somewhere, someone is still living with hope that they can make the old tool work.

If you go ahead with the implementation with this looming over your head, you’re likely to run into hurdles along the way and slow down the process.

Possible remedies:

• Start with why. Explain the core need to move to a new ITSM tool.
• Crowdsource ideas and requirements for the new tool.
• Keep everyone in the loop right from the start so no one can say, “Well, I didn’t know about it so can we work on it from the beginning?”

Number 3: “But, That’s How We Used to Do It In Our Old Tool!”

Once you’re past the hurdle of convincing everyone to move off the old tool, the next challenge begins. You find that everyone wants to recreate the same mess in the new tool.

This happens because the configurations and processes have existed since the time before dinosaurs and no one really knows why, hence no one really wants to change. The easiest thing to do at this point is to simply recreate things as is. Well, it’s not a good idea.

Possible remedies:

• Go back to the drawing board, and question every process, rule, and configuration in place. You will not get a better opportunity!
• Rule of thumb: Delete by default. Migrate only if it’s really important.
• Don’t be afraid to leave things out. If it’s really important, it’ll find a way in.

Number 4: “Adding a New Field? Let Me Call the Tool Vendor”

Things are moving along quite well and you and the ITSM tool vendor are working closely. Too closely, one might think! It’s great to see that the vendor is incredibly helpful, but you really shouldn’t have to depend on them for everything.

If you’re depending on the vendor to make minor modifications to the tool (either lack of knowledge or the tool doesn’t allow you), it’s bad news.

Possible remedies:

• Try out a proof of concept during tool evaluation. This should eliminate this problem completely.
• During the sales cycle, question the tool vendor on adequate documentation and knowledge base for self-implementation.

Number 5: “Yes, That’s Right. We’re Importing Data on 3.4 Million Tickets.”

I’ve always had mixed reactions when I throw out this opinion, but I still strongly believe in it. Do not migrate old tickets unless you absolutely have to. Trust me, you don’t need the historical data you think you do!

Here’s the trouble. When you migrate old ticket data, you’re also migrating the data model: the same fields, the same labels, and the same problems that existed. The new tool is a great way for you to start from scratch. You don’t want baggage weighing you down.

Possible remedies:

• Run two  service desks in parallel if you have to. I’ve seen this strategy work out many times, and it is worth the pain.
• If you are required to hold historical data for “audit purposes,” clarify if they need to exist in the current ticketing system. If you simply need a data dump, that should be easily doable.

Number 6: “Wait, What? We’re Changing Our ITSM Tool?”

So, you’re all set! You’re just about to roll out the new ITSM tool to the entire organization. You call a meeting with the department heads and none of them are even remotely aware that the tool is changing! Bad sign, right there!

Rolling out an ITSM tool that only IT knows about is like opening a restaurant with no menu. No one’s gonna know what to order!

Possible remedies:

• Work with your marketing team. Create a launch plan.
• Roll out a beta version with a few power users. Gather feedback. Improve.

We Can Fix This

Of course, there are many other phrases that you shouldn’t hear during an ITSM tool launch  (“There’s no budget!” “Let’s just change the colors of the existing tool.” “We can’t find any tool that runs on Windows XP”). But the ones I’ve listed are the ones that are still fixable!

What would you add to the list?

Sanjeev NC started his career in IT service desk and moved over to process consulting where he led award winning ITSM tool implementations. Sanjeev is passionate about user experience and evangelizes a concept called selfless service as an evolution of self-service. Sanjeev was also a highly commended finalist for Young ITSM Professional of the year in itSMF UK’s annual awards. Sanjeev is currently on a mission to ensure that every customer support interaction yields the best possible experience. Follow him on Twitter @yenceesanjeev .