This is a story about Peter. He’s a hard-working family man, has a wife and three kids. During the week he’s busy managing an IT department with around 200 employees. Currently, he drives an old Volvo which fits his demands. It brings him from home to his job and at the weekends he goes out with his family. But the car breaks down and he needs to buy a new one. So he starts the process of selecting a new car. He has some preferences for the brand. His father used to drive Volkswagens and he hears good stories about Toyotas from his colleagues. Together with his family, he starts to go to car dealers. Looks at different models, colors, and features. He discusses with his wife what the important features should be and lets his kids sit in the back of the car. They agree that safety is a very important topic and comfort is second. They do test drives and finally, they both have the best feeling about a Volkswagen. Although all the cars they looked at are almost similar regarding price and features they feel that Volkswagen fits their requirements best.
Please keep reading to see how this analogy relates to IT service management (ITSM) tool selection.This article by @StephenLey shares a very interesting analogy around #ITSM tool selection, with some solid advice on how to ensure you review your options & vendors successfully. Click To Tweet
There’s also a need to select a new ITSM tool
At work, Peter is starting a project to select a new ITSM tool. The current tool they have doesn’t meet their demands anymore. He hears complaints about it, his staff can’t get the right information out of it, and it’s not user friendly. They also want to move all their applications to the cloud. He knows from experience that it isn’t always the tool that is the problem, but this looks like a good moment to freshen things up and start with a new tool that can support the new way of working.
So, Peter creates a project team and gives it the assignment to write down all the requirements that they have. The idea is to invite three vendors who will be asked if they can meet the requirements. Based on their answers they’ll select two vendors to demonstrate their tool and its capabilities. During the requirements sessions, all project team members can add requirements, such that they cover most of the wishes of the organization and prioritize them via the MoSCoW method.
All the ITSM tools met the requirements
After a few weeks of hard work, they’ve finished the requirement sessions and ask three vendors to give their reaction to it. Peter is proud of the work that has been done! They get a lot of feedback from the vendors and it seems that they all can meet the requirements. So, Peter decides to have a meeting with the project team to discuss the results.
During the meeting, it seems that a few people have experience with one of the vendors and are convinced that this vendor should be part of the demo. Because all the vendors meet the requirements and they cannot come to a decision of which two to invite, they decide to invite all three vendors for demo sessions. Again, Peter is happy with the results – the project team will have enough choice in vendors, and they have a good prioritized list of all their requirements.
Making sense of the ITSM tool demos
A few weeks later, after all the three vendors have demoed their ITSM tools, and Peter meets the project team members. There’s a lot of discussions. John, a service manager, says “Vendors showed functionality which was not in the requirements but looks very interesting for the future.” Ed, a service desk manager, is impressed with the usability of one tool and likes the way that demo was given. This gives him a good feeling about the vendor and their ITSM tool. Carol, a senior buyer, says that one of the most important criteria is cost, and the tools that are now the favorites are the most expensive ones. Now Peter has a problem. All the vendors meet the requirements, and all the ITSM tools have interesting features. There is a price difference but the most expensive one with the extra features can help save money in other areas within IT.Of course, you cannot compare buying a car one-on-one with buying an ITSM tool. But there are some steps in the process of buying a car that can be used in selecting your #ITSM tool. Here @StephenLey explains. Click To Tweet
Back to the earlier car purchase
How could Peter have prevented this dilemma? And why was buying a car with his family so much quicker and the result far more satisfying?
Of course, you cannot compare buying a car one-on-one with buying an ITSM tool. But there are some steps in the process of buying a car that can be used in selecting your ITSM tool.
1. Requirements gathering
Many organizations start like Peter by writing down all their requirements. However, when we buy a car we don’t even think about the standard requirements like it should have wheels, a steering wheel, etc. We assume that all those basic requirements are already met, otherwise it’s not a car. The same is true with selecting an ITSM tool, they can all register incidents, changes, problems, etc. They all have the basic functionality to support the ITIL processes for example. The usage can be somewhat different, but they all have the functionality.
2. Involve vendors in the early stages
When buying a car you go to your dealer for advice. Maybe you did some research upfront to narrow down your brand preferences but after that, you go and get advice from the market. In your ITSM tool selection, you can do the same. Invite ITSM tool vendors to start with. Let them show the capabilities of their tool and the features they have. This gives you a good idea of what is possible and what not.
3. Focus on themes
A theme is very different from basic requirements. When buying a car you start by thinking about themes. For example, do I want a convertible that looks sexy and will impress my fellow IT coworkers, or do I buy a mini-van which helps me to transport goods from A to B?
With a select group of stakeholders, define which themes are important now and in the near future. What is important? Integrations? Usability? Automation? Based on these themes you can gather more specific requirements from your organization, and these can be used towards vendor selection.
4. Work together with the vendors
Like with a car dealer, you can find some information on the internet. If you want to know everything about a specific model, then you go to the dealer.
Vendors are not the enemy. For them, it’s as important to have a good fit with your organization as it is for you. So, invite them in sessions where you discuss the themes and what they can offer. Based on these sessions you can set requirements per theme. Besides getting information about the product, these sessions also give you an emotional feeling about your vendor. Do we get along? Nobody likes the type of car dealer who’s just in it for the money, right?When it comes to #ITSM tool selection, remember that vendors are not the enemy, says @StephenLey. For them, it’s as important to have a good fit with your organization as it is for you. Click To Tweet
5. Set a challenge
After you’ve set your requirements per theme organize a challenge over five days. Look at this as if it’s a test drive. You don’t buy a car without driving it, or do you?
Give each vendor (maximum three) several use cases that they need to configure. Every day there is a short Q&A session where they can ask questions regarding your requirements. During this week you have close contact with these vendors, this way you can experience how they work and communicate. At the end of the five days, they can demonstrate what they’ve achieved. And the result is not about if they’re finished, but about how they configured the solution.Trying to narrow down your #ITSM tool selection? How about giving each vendor a challenge? Up to three use cases that they need to configure, says @StephenLey. Click To Tweet
6. Make a decision
Based on the experiences during the selection process, the way the vendor took on the challenge, the results of the challenge, and of course pricing, you can make your decision. During this selection process, your employees get to know the tool well and the configuration of the challenge can be used in the implementation.
The moral of the story: we try to objectify ITSM tool selection by endless requirement lists and a strong separation between vendor and customer. While 80% of the requirements can be covered by every vendor. The other 20% you want to shape toward the tool of your choice to avoid customization.We try to objectify #ITSM tool selection by endless requirement lists and a strong separation between vendor & customer. While 80% of the requirements can be covered by every vendor – @StephenLey Click To Tweet
After finishing these six steps you know your vendor, you know your ITSM tool, and you know what your stakeholders think about the quality, usability, and possibilities. You know which ITSM tool they like most and which one “drives” best.
And Peter and his ITSM tool? Well, they ended up with an implementation project where a lot of requirements needed to be changed and a lot of customization was needed. It took longer than expected and the results were not that promising.
Sound familiar? Please let me know any ITSM tool selection advice you have to share in the comments section below.