The Most Important Ingredients for a Successful ITSM Tool Implementation

An as ITSM consultant, one of the questions I get asked most frequently is “What do I need to consider for a successful ITSM tool implementation?”

Like baking a cake, the key to success is a delicate balancing act of using quality ingredients at the right proportions. In this case, the ingredients are a few key activities with correct proportions of people, process, and technology.

With that in mind, I’ll share a few key items that I use, and I have accompanied them with some real-life examples to further illustrate their importance.

Understand Why You’re Doing This

For those looking at any initiative, the question of “Why” should always come up first. You might even have more than one why. But when you start to scrutinize the reasons, you will start to see where these might roll up to a common theme.

Before I even start to work with a client, I have a couple of brief coffee meetings with the people who are looking to implement the tool. This is just a general chat to identify what they are looking to achieve, get a sense of their support organization, what their business does overall, and some background on their culture. Once I get a basic sense of what they are about, I ask them why they are looking to change up or upgrade their tool. They may not have a complex answer, but they should easily be able to verbalize that. This is their why.

Let’s look at an example.

I recently met with an organization that was looking to move to a new ITSM platform because they were having service delivery challenges. They had next to no visibility on what was happening from the reporting in their current application, which was built in-house. While it worked for them in the beginning, they were looking to mature their processes, and their tool was no longer enabling them to be able to do that.

This was their initial why.

As a consultant, I asked them where they thought I would be able to help. They knew that their service delivery was slow, that their resources were over capacity, but didn’t know how to quantify that. When I asked them how they were reporting on their performance they said that they couldn’t do it consistently or easily with their current tool. This was one of the primary reasons that they were looking to move to a new platform. Being able to bring value to their organization from a support perspective was limited by the fact that they were flying blind due to the inability to not only report on their performance but use some level of information to make the improvements that they knew that they needed to make but could not show.

Understand Your “As Is” State

You can’t know where you are going until you know where you have been is a refrain I find particularly relevant when we are talking about changing up an ITSM tool. No matter the state of your current environment, you need to expose all the good and the bad to get an overall picture of what is working well and areas that require attention. What’s happening in your environment is not as secret as you might think. You may think no one knows when something is not working, but trust me, your business does.

When organizations have decided that they need to move to a new or updated platform, they often are already thinking about the future state, wishing to abandon all that is wrong with the here and now. The key to realizing value will be evident when we can illustrate the amount of improvements that can be made as a result of moving to a new tool. In some cases, I have found that documenting the current state highlighted some other areas of improvement that would have otherwise either gone unnoticed or unrecognized.

Here is another example.

A previous client I had outlined that the rate in which incidents and requests were being resolved seemed to be reasonably good for the most part as it met the established service level requirements agreed to by the business. However, the business feedback on CSAT surveys told a different story, indicating that service was slow or inconsistent. They couldn’t figure out where the disconnect existed.

When we took a closer look at the metrics, we saw that email and phone escalations were the dominant methods to connect to support. These were also the methods that had the quickest turnaround on resolution. This supported what the IT director was confused about, that overall the service was provided in a timely way. However, when I looked at their self-service/portal usage metrics (which were tied to the customer satisfaction reviews), I saw that the rates were well over the service levels and loaded with incidents that were re-opened. This was definitely an area that requires improvement whether we upgraded the tool or not. In fact, if this issue doesn’t get addressed, it will likely remain in the newer version or new tool, leaving people to believe that this might be some form of technology issue with the platform when it is not.

Determine the “To Be” State

Keep in mind that in a continual improvement environment there really is no end state, so we want to think about what this upgrade or implementation is looking to achieve in a time frame given. If we are looking at this from an agile perspective, we want to consider what we can deliver in short timeframes while still achieving the “why” we asked in the previous paragraph. Sometimes this can be tough as everyone will want to have everything included as fast as possible. This type of agile work will involve going through the steps multiple times over and over, starting with a new or modified why, an as is state and new to be.

Let’s look at another example.

One company was used to working in a waterfall deployments style. Their hesitation for implementing large projects was that all this effort was going in and the hope would be that this would be done on time and on budget some time a year or more away. In our project, we broke out the work in far smaller pieces that allowed us to get an app deployed and further functionality deployed on regular cycles. This was new to the business that was consuming it, however, they were impressed as it seemed that we delivered the application early (even though we didn’t) and that we were continually developing the app on consistent timelines, improving overall application adoption and satisfaction.

Know What You Really Need

If you have ever gone to one of the larger ITSM conferences and seen all the vendors, you know that the masters of marketing are working hard to get you to consider their application over the many others you will see. It can be an overwhelming experience, especially when you are looking to find the right application to help you.

There is a heap of ITSM toolsets out there, far too many to list. The trick is that, like Goldilocks, there is one that is “just right” for your organizational needs. Understanding where you are right now and where you need to be, it can still be tough to really know what type of tool is going to be the right fit for your organization when they all look so good. In some cases, you might just need an app to get you going and then plan to move to a bigger app in the coming years.

It can be tough to know what type of tool is the right fit for your organization when they all look so good.

In my experience, I have personally met with loads of clients who were looking to move to a new ITSM tool and had very little visibility on the variety of applications that existed in the ITSM ecosystem. In many cases, their backgrounds were in CRM, ERP, or Infrastructure, so they might only know a handful of the popular applications or ones that show up in some analyst firm’s charts.

Spend some time internally to understand what capabilities are important to your organization now and the roadmap for the next few years to see what application will fit in best. In some cases, having an external contractor with tool selection expertise come in to assist might save you a great deal of grief down the road.

Here’s another example.

A client had reached out to me to facilitate an ITSM tool selection. They were using InfoPath forms to track incidents, requests, and changes and wanted to move to a new ITSM platform. The IT director wasn’t particularly familiar with all the tools available admitting she only knew of a couple of the main players in the industry.

The initial discussion with stakeholders was to find out what was truly important organizationally. They had three main needs:

1. That their organizational data was stored locally for regulatory reasons.
2. To have a reasonable amount of support in their geographical area should the application have any issues.
3. They wanted to be able to track all the work they were doing and be able to compile reporting to enable a continual improvement environment.

Given these requirements, their needs could be managed by just about any tool in the industry. The company’s ITSM platform usage wasn’t expected to be large in the start, and with a company size of 2500 people, the applications that they could review was a far larger and different list than they originally had considered. In the end, they went with a mid-market sized application, and from what I have heard, they have been using it for several years with great success.

The Art of Communication

There is a certain art to marketing and communication. It seems to be one of those things that people are either really good at or they will avoid it at all cost. The challenge with an implementation on the scale of putting in an ITSM tool is that it may incorporate project resources who handle the training, communication, and marketing components of the work. Then, when the tool is transitioned to operational teams, these resources don’t go with it, leaving a gap. To avoid this scenario, we need to make sure that we build in the element of a feedback and continual improvement mechanism in the operations of the tool implementation. This is not going to be a technology piece, rather a people and process component.

Consider this example.

An implementation I worked on a few years ago had a fantastic organizational change management expert that made the transition to the new tool look effortless. Because she was a master of facilitation on this, she built in process requirements for each of the ITSM practices that required not only the feedback, but also activities and a governance model to ensure that training, communication, and feedback would complement the continual service improvements initiatives long after she left.

Keep It Simple

There are lots of different ways in which we can ensure that an ITSM tool implementation can be successful. The key is to keep it simple and understand why you are doing it, where you are, and where you want to go. With those foundational building blocks, you can make a choice that is the right one for your organizational needs.

Ryan Ogilvie has been working in the service management space since 2006. A keen student of the service management ecosystem, he first started blogging after feeling a responsibility to share what he’d learned to a wider community. While his professional focus is IT service management, his experience has taught him that leveraging a variety of frameworks and communication styles will enable your business to meet its business outcomes. Follow him on Twitter @ryanrogilvie.