One of my customers was using a very old IT service management (ITSM) tool. It was no longer supported by the vendor, and really didn’t meet their needs, so they asked me to help them choose a new tool, a tool that would better suit their needs and that would be able to support all the new ideas that they couldn’t implement with the old one. I want to share the approach we took to selecting a new tool, and planning the migration, because many of the things we did might be appropriate for other organizations too.

What Is the Vision?

We started by chatting to the manager who was sponsoring this work. We asked lots of open questions:

• What was their vision for the tool, for ITSM, and for IT generally?
• What did they want to be able to do that the current tool was making difficult?
• What budget did they have?
• Were there any time constraints on when the tool should be replaced?
• Were there any other constraints that might affect our work?
• What was their experience of working with vendors, both suppliers of software licenses and organizations that provide software as a service (SaaS)?

This gave us a pretty good idea of what we needed to achieve, at a very high level. It rapidly became clear that what the company really needed was to change the way that IT services are supported, and that replacing the ITSM tool, while vitally important, was in fact only a small part of that. We agreed that the vision for our project was that:

IT service management is seen by our stakeholders as part of value creation.

Where Do We Want to Be?

The next thing we did was to interview lots of people across the organization, not just those who use and support ITSM tools, but also people in the wider business, to understand their issues. Instead of asking people about ITSM tools, we asked:

• What do you do? What is your exact role?
• What differentiates a good day from a bad day for you?
• What are your goals, objectives, and measurements for this year?
• Which of those measurements are most at risk?
• How does the IT organization help or hinder your work?

These conversations were really enlightening. Everyone had issues that needed to be addressed, but they also had some great ideas for how IT could help them. I took extensive notes during these interviews, and then documented the findings as a number of use cases.  Each use case was expressed like this:

As a I need to be able to so that I can

For example:

• “As a change manager I need to be able to assign actions to multiple groups from one change ticket, so that we can all see all the information about the status of the change.”
• “As an HR administrator I need a single point of contact with the ability to pass HR requests between HR staff, so that we can manage HR requests even when the local HR admin person is not available.”

How Do Use Cases Support ITSM Tool Selection?

I have seen organizations using standard lists of ITSM tool requirements, with many hundreds of lines, that they send to suppliers to ask for a response. We wanted to avoid wasting our time, and the tool vendors time, and our interviews helped us to do this.

This information gathering exercise provided us with about 90 user stories, which we clearly needed to refine a bit further if they were going to help us with our project.

So our next action was to assign our use cases to one of two categories:

1. Things that any ITSM tool would be able to do
2. Things that might be difficult for some tools

We were then able to combine many of the use cases that needed similar functionality. We ended up with about 15 high-level tool requirements – a much more manageable number than both a standard ITSM tool requirement list, or indeed than 90 use cases!

Our high-level requirements included things like:

• Good support for complex workflows, including integration with the tools used by our development teams and our external support vendors
• Flexible ad-hoc reports and dashboards, as well as a comprehensive set of standard reports and dashboards

I’m sharing these examples in order to show you the level at which we set these requirements. We didn’t specify more detail than this, as we wanted to see what the various vendors had to offer.

How Do We Get There?

We decided that we wanted to take an agile approach to implementation of improved ITSM processes and tools. We had already started well by agreeing on a vision with our sponsor, and by talking to all our stakeholders. The next thing was to think about what would make a minimal viable solution for our first iteration.

What we decided to do first was implement change management using the new tool, while continuing to manage incidents using the legacy tool. This approach, which may not be suitable for you, made good sense in the specific business environment concerned, because it allows us to familiarize ourselves with the new tool without having to simultaneously introduce it to the wider pool of users and business managers and provide the training that will enable them to use it effectively. Later iterations of the project will gradually migrate other ITSM processes, as well as adding new functionality to those we have already migrated.

Did We Get There?

We set measurable targets for our first iteration, so that we could judge how well we were doing and make improvements to our plans for future iterations.

I’m going to leave off describing what we did next, because I think that’s enough for one blog. But do let me know if you want to hear more about this project and I may write a subsequent blog explaining what happened afterwards.