OK, it really should be the “500 shards of ITIL” but it just didn’t sound as sexy.

“ITIL is sexy?” I hear you cry. Maybe not for most, but IT service management (ITSM) is something many of us are passionate about. Or, to be more precise, the delivery of high-quality, business-centric IT services is something many of us are passionate about – with ITSM purely the means to that end.

Anyway I wander from my point . . . the “500 shards of ITIL” I refer to are the 500 extremely granular, ITIL-espoused capability points that far too many organizations commonly use as the basis for new ITSM tool selection. As I wrote in a recent blog for the ITSM Review: “the current method of creating RFPs (request for proposal documents) and selecting vendors based on a cut-and-paste, ask-for-everything-possible-mentality is so, so flawed.”

In a soon-to-be-released market overview of SaaS ITSM tools I add that “Customers often ask the wrong questions during product evaluations and therefore don’t get the answers they need.” Think about it – multiple choice is far easier to pass than an essay-style exam, and do you really need that infrequently adopted ITIL-espoused capability? If you don’t, why on earth are you asking for it?

“Be careful what you ask for because you just might get it.”

So think about what you ask for in RFPs. By asking for the 500 ITIL-espoused capabilities you are probably making the most functionally rich tool the favorite (bar excessive cost and perhaps complexity). I deliberately used a variant of the phrase “means to an end” above – not only is this true for ITSM, it is also true for the enabling ITSM tool. We should be less concerned about the means and more concerned about the end, i.e., the business outcomes – what do we need to achieve for the business through the ITSM tool? This is what we should be asking for.

IMO we need a completely different line of questioning that will hopefully elicit a completely different line of response from ITSM tool vendors. A response that is firstly tailored to the specific RFP’s questions and secondly one that demands a real understanding of the customer. You should be buying a solution to one or more issues, not just buying technology – so make sure that you are adequately communicating the issue(s) to the vendor(s).

It’s no different from the “informed” internal customer who asks IT for a “green Ford Focus” rather than saying we need something that can transport us from A to B (note that the solution might not actually be a car) in a timely manner, that is aesthetically pleasing, and is available at a reasonable price. Actually I’m going to disagree with myself here – it is different, it’s worse. What we are also doing is adding in loads of costly “optional extras” that we will never use – are you really ever going to do capacity or IT financial management? Are you even organizationally capable of doing so? Probably not, so why base your tool selection decision on it and why pay for something you will probably never use?

The pain of the current ITSM tool RFP process

The pain is at least two-fold:

  • Customers end up with an ITSM tool that probably isn’t as good a fit to their needs as they would have wanted. They might even quickly regret the investment and look for another tool far sooner than they would have liked (we really shouldn’t put up with the high rate of ITSM tool churn – it’s not just the vendors’ fault). More importantly, the IT organization has probably failed their customers – they might have achieved the means but did they achieve the end? I personally would wager not.
  • ITSM tool vendors don’t like the multiple-choice-style RFPs for a number of reasons. They are tedious to complete (just think of responding to yet another 500 lines of yeses, noes, and fudges), the vendor knows you will probably never use much of this (not without significant investment in people and processes), and they have probably seen the same RFP before. They might even recognize another vendor’s words in the RFP – there’s nothing like a foregone conclusion to limit a vendor’s commitment to an RFP. Ultimately it distracts from the vendor’s ability to deliver you a fit-for-purpose solution. Remember, not only do vendors want you to buy their tool, they want you to keep using it. In fact they want you to use more and more of its capabilities – from both a “stickiness” and an up-selling opportunity.

There has to be a better way . . .

. . . and that better way has to start with customer organizations.

So, when you next tender for an ITSM tool, try to break the cycle:

  • Think about what you really need from an ITSM tool.
  • Step back to think about what you need to accomplish with it – and this is from a business outcomes, not an IT operations, perspective.
  • Limit yourself to what you will realistically use both now and in the future.
  • Push the envelope in terms of what would really help deliver to your business rather than trying to pander to the god of ITSM trends.
  • Consider how the people actually using the tool will be helped or hindered by complexity as well as the UI.

To finish, also consider how a dollar saved in tool licensing or subscription might cost you ten dollars in its operation or negative business impact over its lifetime – consider the bigger TCO picture.

As always your comments are encouraged and appreciated.