As Joe the IT Guy said in his recent HDI blog on selecting a new IT service management (ITSM) tool –“Selecting any new technology is a serious matter.” In particular, there’s little fun to be had with the request for proposal (RFP) process, for all the involved parties. And, having been involved with RFPs on both sides of the seller-buyer divide, I can tell you that RFPs are never fun, but even more worryingly, they can also be dangerous.
You might be thinking “Dangerous? Really?” So consider one of my favorite, and most oft-used, ITSM tool selection statements – “If you ask the wrong questions then you’ll get the wrong answer.” In my opinion, we continue to see a never-ending series of “wrong answers,” i.e. less than successful ITSM tool implementations, that has industry analysts stating that ITSM tools are, on average, replaced every “n” years (where n is usually between 3-5 years depending on the analyst firm).
The ITSM Tool Blame Game
Many will blame this ITSM tool replacement cycle on the technology implementation process or the fact that key people and process issues weren’t addressed when moving from the old tool to the new one. These people are not wrong. However, more blame needs to attributed to the tool itself – not that the new tool is imperfect but the fact that the tool might not have been the best option for the procuring organization. The wrong questions were asked and the company received the wrong answer.
Joe’s blog touches on this, with Joe stating: “Be clear about which ITSM tool requirements are ‘must haves’ and those that are merely ‘nice to haves’.” But there can be many other bad decisions made between the creation of business requirements and the eventual ITSM tool selection; with the RFP process a platform for many of them.
Getting Your RFP Right
I’ve written about this before, in a blog called “50 Shards Of ITIL – The Bane And Pain Of ITSM Tool Selection” (and yes this was before everyone and their dog was writing “Fifty Shades of Grey” blogs), where I state that companies need to break the existing cycle (of RFPs leading to the wrong ITSM tool being selected) by:
- “Thinking about what you really need from an ITSM tool.
- Stepping back to think about what you need to accomplish with it – and this is from a business outcomes, not an IT operations, perspective.
- Limiting yourself to what you will realistically use both now and in the future.
- Pushing the envelope in terms of what would really help deliver benefits to your business rather than trying to pander to the god of ITSM trends.
- Considering how the people actually using the tool will be helped or hindered by complexity as well as the UI.
Plus, also considering 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.”
Of course there are many other sources of opinion and advice on RFPs available on the Internet but it’s good to see that industry legend Roy Atkinson is starring in an upcoming HDI webinar on the topic. And Roy being Roy, he chose to seek insight, and scar tissue, from the many IT professionals that make up the Facebook Back2ITSM community, posing the question: “What is the most common mistake you see organizations make when making an RFP for products or services?”
And the survey said…
10 ITSM Tool Selection RFP Tips
I’ve flipped some of the common RFP mistakes crowdsourced by Roy, from the cited individuals, into ten ITSM tool selection RFP tips. There are other mistakes offered in Roy’s Facebook thread but these ten are a great place to start:
- Focus on the right things.
Common mistake = “(RFPS are) too long, too much detail of things that should be left to the supplier, and too much focus on how the results are achieved rather than what the results should be.” (Stuart Rance)
- Don’t be led astray by the available technology. Common mistake = “Unclear requirements, listing a feature set from a product rather than the outcomes they require…” (Daniel Card)
- Commit to specific business outcomes. Common mistake = “Not focusing on the outcome of what they want it to do, lack of or inadequate design of their business process for which the product or service is meant to support and therefore poor requirement understanding.” (Simone Jo Moore)
- Start out, and stay, impartial. Common mistake = “Being a vendor fan boy, and not stating this in the RFP but refusing to consider any option that does not include technology from vendor [INSERT NAME HERE].” (Daniel Card)
- Don’t get lost in the weeds. Common mistake = “Too much detail and focus on commodity functions, at the expense of defining what's really important, i.e. to find a suitable partner to work with.” (Barclay Rae)
- Take an outside-in, i.e. customer-focused, approach. Common mistake = “Looking at it from an inside-out perspective as opposed to an outside-in approach, with too much focus on what IT needs instead of the business.” (Elaine Hutton)
- Focus on your needs, not others’ needs. Common mistake = “Most RFPs I see are based on feature/functions that come from templates created by Gartner and PinkVERIFY. Sometimes the same question is asked multiple times with slightly different wording, but has the same answer. The items may or may not have any bearing on how the customer wants to use the technology.” (Brian Hollandsworth)
- Balance today’s and tomorrow’s requirements. Common mistake = “Building the RFP around past requirements rather than the future, though close behind is building it around future requirements while ignoring the current technical and cultural debt.” (James Finister)
- Ask vendors for a solution, not specific functionality. Common mistake = “Describing the solution rather than the objectives and outcomes, and letting the expertise of the supplier show (or not) with the solution they suggest.” (Matthew Burrows)
- Question some of the vendor’s answers to your questions. Common mistake = “Taking the vendor’s responses at face value. Vendors know they are jumping through a hoop to get to the next ‘filter.’ The problem is that the honest vendors get eliminated and the less than honest ones make it through. And often you don't find out until much further down the road.” (Ken Wendle)
So there you have it – ten crowdsourced tips for getting a better result from your ITSM tool RFP process. Is there anything you would add or disagree with? Let us know in the comments!