Why Is Buying An IT Service Management Tool Like Buying A Car?

It sounds like the start of a bad Christmas cracker joke. Maybe the title of this blog should actually be, “Why Should Buying An IT Service Management (ITSM) Tool Be Like Buying A Car?” but let’s see where this goes. I'll deliberately avoid talking about salespeople.

I sometimes talk about new application development in the context of acquiring a car: in that the business often says “we want a green car” to IT rather than saying “we want a means to get from A to B that is aesthetically pleasing.” What I realized responding to a Forrester client inquiry this morning is that the same is true in selecting an ITSM tool.

How should one buy a car?

Let’s look at ITSM tool selection in terms of needing a new means of transport/business support, as you might not actually need a car:

  • Work out what you need it for (is the need for a car, tractor, plane, or pony?)
  • Identify the features you need based on what you need to achieve rather than what is available (will you use 16 cup holders?)
  • Identify what features you need/value most and don’t lose sight of them
  • Work out what you can afford (this might impact the above)
  • Speak to your “personal network” about their experiences with particular models and vendors
  • Look at what is being said on the Internet (the social commentary)
  • Consult aggregators of opinion and experiences (analysts and some consultants)
  • Speak with existing customers (and not just the ones that the car sales person points you at)
  • Ask for what you actually need
  • Always, always have a test drive and kick the tires (that is a test drive by the people who will be driving the vehicle in their job rather than the people who watch them drive). Get a pilot implementation
  • Haggle, and haggle more, in what is a very competitive market
  • Make your decision on what you actually need; appreciate that often the biggest/flashest or cheapest aren’t best
  • If you don’t like the ride, or if there is an annoying knocking sound in the boot, go back to the vendor and mention it/complain about it
  • Think about continued usability and servicing before you start to remove or add bits to your vehicle

The ITSM tool selection reality

How much of the above do we do with ITSM tool selection? Not enough IMO.

How often do we plod through an RFP exercise without an appreciation of business outcomes and too great a focus on technological prowess? And don’t start me on the fact that too many organizations borrow an RFP “skeleton” from a third party and then add to it. Thus we end up with a very complete tool but not necessarily one that best meets our needs. It’s what I call the “capability gap” – where organizations only use 30%-50% of what they ask, and ultimately pay, for.

Food for thought? I hope so.

As always I value your feedback, opinions, and additional car buying analogies.


Related blogs:


If you want to know me...come live with me

Stephen - As a vendor I've been on the receiving end of more than my fair share of RFPs and although some are well thought out and give real attention to the business problems the tool should solve, a fair number don't. This is frustrating for the vendor, as we'd rather show how the tool can make a real difference, instead of explaining compatability with 15 generic ITIL processes, most of which will never be deployed.

It whole-heartedly agree that it's better for the buyer to include a pilot in their selection process. Get the vendor in and pay them to configure the solution with a subset of the processes that are most critical during the initial stage of implementation. That way, you can at least be assured that the tool is the right fit on day one and can get your hands dirty, using your own data to get a real reflection of how the tool performs in your environment.

Many vendors will happily commit to such a pilot and usually will charge only for the professional services needed to implement the bare minimum (no licence or maintenance costs to pay). Typically the work is not wasted, as if it’s done correctly, the initial configuration can be used for the eventual live system. Granted, some vendors with highly complex tools are not happy to commit to a pilot and this should be fair warning to the buyer of the amount of work that will be required for full implementation and ongoing customization. We have one customer that implemented our tool to replace a legacy ITSM solution and they said that the cost of purchasing, implementing and 12 months maintenance of Supportworks was less than it cost them to run their old solution for one month. If I was personally selecting a tool, I’d rather do a little bit of work up front, than repent at my leisure later on.

The added bonus of a pilot approach is that you get to know the vendor and get a good feel for how you will be treated as a customer. So although the quality of the RFP response and the vendor demo can provide some comfort factor when shortlisting, there’s no substitute for real experience with the tool and the vendor. After all, over the long term, the relationship with the vendor, is equally, if not more important than the capabilities of the tool.

Look to the future

I've been responsible for over 400 implementation of ITSM at various companies around the world.

One thing I can say with utter confidence about choosing their ITSM tool, is that the needs that a company sees now will not be the needs they see in three, or five, years.

Companies learn and grow. Picking a tool that meets their needs, right now, and little more - to save 20% of the tool cost may cost them many times that in the not too distant future.

Total process and technical implementation costs are, in the final analysis, three to five times the the cost of the software. It seems to me that companies should, therefore, consider the costs of redoing much of the technical implementation against the opportunity costs of expanding into related processes where there are some real cost and risk optimization to be realized - software asset management, standardization driven by architecture, multisourcing management, governance and IT financials from an investment based budget, etc.

It's more than 'test drive'. Go somewhere real.

Chipping in as another Vendor, and using Stephen's car analogy:-

It's not enough just to test drive the car. Think about the destination. Where do you and your business need to go? What are your own (not the Vendor's) processes? Can the car actually take you to your destination or is it quietly dictating where you will end up ?

Some of the best evaluation activities I've seen have involved the customer being very clear about the support processes they NEED to follow in their business. They present clear process/flow diagrams, and say to the Vendor 'here are OUR support processes, show me how your product would implement these'.

In fact, go one better than that. Say 'show me, here, in front of me, how WE can change the way this solution works to match the processes we want to follow in our business'. As the comment above mentions, the way you operate IT Service changes all the time. Can you change the process flow yourself? You need to. Do you need developer/code skills? Can it even BE changed? You should be able to take ownership of your own ITSM future.

I think that are great

I think that are great services.Nice information..Thanks!