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.
We started by chatting to the manager who was sponsoring this work. We asked lots of open questions:
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 <customer> value creation.
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:
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 <role> I need to be able to <do something> so that I can <create value in a specific form>
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:
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:
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.
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.
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.
You can find more ideas on the topics discussed in this blog in the excellent white paper “Your 7-Point Checklist for Better ITSM Tool Selection” by my friend Stephen Mann.