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 realised 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 organisations 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 organisations only use 30%-50% of what they ask, and ultimately pay, for.
Food for thought? I hope so.
Posted by Stephen Mann