50 Shards Of ITIL – The Bane And Pain Of ITSM Tool Selection

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.


An ITSM tool that can grow with you

Great blog Stephen. Generic RFP checkbox exercises certainly are not the best use of time for both parties and there is a better way as you describe. The responsibility falls on the customer to truly understand the business outcomes they are trying to achieve now and in the future. These requirements must be clearly communicated to participating vendors to ensure the best possible solutions are presented.

One point I would elaborate on is that when considering a tool, have a long term vision in mind beyond 3-5 years. Select a tool that can not only help you succeed at a lower process maturity level today, but one that is flexible enough to take you to higher levels of maturity in the future. Customers who select "out-of-the-box" ITIL tools because it's easy today may be restricting themselves to the box the vendor believes is THE best practice for every customer on the planet. It is simply not possible for one set of processes to fit all. Every customer is unique and requires some tailoring to make a tool fit well for its intended purpose. As processes mature and outgrow the tool's capabilities, customers may find themselves in a rip and replace situation if the tool they chose cannot take them further. This can be quite disruptive when done every 3-5 years.

One point I'll make that was missing from your suggestions is the importance of taking ITSM tools for a test drive in your actual environment, not just in a controlled demo. Create meaningful use cases and demand vendors prove they can meet your needs. There is nothing worse than buying something only to realize, it doesn't work as advertised. You wouldn't buy a car without a test drive. Many people won't even buy clothes without trying them on first. An ITSM tool is a business critical investment that requires the utmost scrutiny when making a selection.

Customers who choose a flexible tool capable of meeting requirements at any process maturity level may be quite surprised at how fast other departments outside of IT want to jump on board to automate their processes with the tool once they learn how easy it is. Consider this possibility as extra an return on your investment.

Test driving?

Great point Brian ... I did link to another blog that mentions it but I should have underlined it here.

So true!

We might as well send back the link to this blog post next time we receive a 500-lines-copy-and-paste-multiple-choice-RFP.

Hi Ingo, you are not alone ...

... I think most ITSM tool vendors, while glad of the opportunity to win new business, wish that RFPs were more about what is actually needed rather than a mythical ITIL-inspired wish list.

It's Like Buying A House!

Great blog Stephen. I recently wrote a paper that likened buying an ITSM tool to buying a house. You need to specify what it is you want e.g. holiday home, investment property, residence etc. That is, your business imperatives. It is also a long term investment so you need to ask the "right"questions and get the best fit for business needs. You also need to allow for growth. If it was a house you were buying you would be considering whether the family would grow or whether you will need a home office in 3-5 years time. Same applies for an ITSM tool - what are the likely future business needs and how will they be catered for.

The paper I wrote was sponsored by Axios Systems albeit I am absolutely tool agnostic. They wanted to assist service management make the right choice so that vendors dont get kicked out every 2 years and another one selected. Not their fault! The choice and most likely implementation was wrong. Why start massive renovations to the house if that wasnt the intention in the first place. So dont customise the tool to death and then wondered why it doesn't work!

The paper can be downloaded from the Axios site. As they sponsored it, i think that is only right that I direct anyone who wants to read it to their site. You will have to register to download so sorry about that.




Thanks Karen, agree but would go further ...

... what are the needs that make you think you need a house? Would a caravan be better ;)

I'm sure the paper covers things like buy vs. rent too :)

A Nice Cup of Tea

Stephen, I must congratulate you on having the audacity to write some of the sanest words I have read in such a long time. We've had the same business outcome concepts in our software offering for nigh on 10 years now, and still organisations are fixated on doing what they think is the right thing, rather doing what is right for their circumstances. Unfortunately, the growth of ITIL has only served to compound the issues (no pun intended) - you only have to read the LinkedIn posts where people spend days and weeks debating over the right name or process to use - during which time they didn't notice the customer gave up and went somewhere else.

As we English are prone to say when expecting everything including the kitchen sink, "does it make the tea?". Well forget the tea, what do you need to achieve? Forget the details, forget the kitchen sink, there's a reason the words in the phrase "people, process and technology" are in that order. If you haven't identified the first two, then jumping straight into the third is going to get awfully expensive, and more than just in licensing costs.

As a vendor, we'd rather have a conversation than an RFP, although we understand that's not always practical. We'd rather sit down over that cup of tea and understand what you need to do - and then we can give you an honest answer as to whether we can help you or not.

Once again - thanks for a great post!

The blame is shared...

I received one this Monday, with a Friday deadline. A full cut and paste xls file, not from a vendor, but from a research company! 362 pure ITIL compliance questions, each wanting a yes/no, and a detailed description. While non-vendors convince prospective clients that an RFP is a vital step in the evaluation process, and offer dumb, application-blind, RFP spreadsheets, this will not end.

This is a great description of what an RFP should be:
"Unlike an RFI, a request for proposal (RFP) is a formal request sent to a vendor or group of vendors for specific responses as to how their company, products, and services can meet the organization’s unique requirements." http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_04796...

When vendors receive a big stupid RFP, they should not complete it, but take the time to help the prospect see why this is not the best way to go. Vendors should do more hand-holding to help the buyers generate a customised RFP, even if it's not going to make an immediate sale, it will buy goodwill and build a good reputation.

Thanks Scott ...

I have heard of the negative part a consultant's "toolbag" of templates can play in the tool selection process from many tool vendors.

A Way Out?

Stephen, great blog and I fully agree. I think it’s an overall problem and characteristic of the ITIL bloat we've all seen. At HP I've seen customers grappling with the endless lists of functionality. In some ways I think the evolution we’re going through now with cloud is an opportunity to simplify some of this and focus stringently on the business outcomes you’re trying to deliver.

Moving from a license to a subscription model provides the opportunity for both customers and vendors to focus on the essential services required to deliver a core ITSM capability. A subscription model implies "pay for what you use" which moves the discussion from feature/functionality to adoption and consumption. The TSIA have a great book "Consumption Economics" by J.B. Wood, Todd Hewlin and Thomas Lah that describes how the shift could impact software and tech services companies.

Full Circle?

Stephen - late to this one... but your tweet today dragged a thought out of me - isn't this a case of the definition of ITSM being left to those who sell software, and volunteer to write the reference books, and help you with forming an RFP?

I mean - who thought a CMDB was a must? Who then followed it up with the ludicrous idea of a service catalog without suggestion IT should actually go on a product management class first, or call in the one skill that is trained to craft marketing collateral? Oh and don't get me started on the service portfolio.

OI wrote (dated perhaps) an article on all this shiny object stuff nearly 2 years ago "Canary in a Colamine" here http://www.servicemanagement101.com/index.php/easyblog/entry/canary-in-a...

Its long overdue our professional realized the IT on the front of ITSM is SILENT.... (well I say it stands for invisible technology) and folks need to learn a whole lot more about what it mans to be a 'service provider' before they attempt this stuff...

Unfortunately, service is something that you experience, and it has outcomes in the mix - can't get that directly from an ITSM tool...