ITSM toolset RFPs (or RFTs, RFQs, RFIs – whatever you call them in your organisation) are painful. They drag on for too long and require a lot of effort and you still end up with a vendor/tool combo that doesn’t meet your needs, or that costs you more than you budgeted for. And then what happens? IT limps on, hamstrung by workarounds and compromises and, before you know it, you’re back to the drawing board repeating the whole painful process.
Having spent over a decade helping organisations evaluate new ITSM toolsets, here’s my list of the ten most common pitfalls. Avoid these and you’ll greatly improve your chances of ending up with a solution that’s right for you:
- Not enough research is conducted to understand the latest capabilities of the toolsets out there. This results in RFP documents being issued that don’t ask for things because their authors didn’t even know the capability existed.
- The RFP revolves around a list of detailed functional requirements rather than a list of the outcomes you want to achieve. For example, “The Change Record must have an impact/likelihood matrix for assessing change risks” (bad) versus “The Change Requester must be able to determine the degree of risk presented by a change” (better). When requirements are too prescriptive, better solutions are overlooked, or worse still, time and money is wasted on modifying the chosen toolset to do things in a less effective way.
- The RFP is issued to too many vendors, usually as a result of a lack of upfront research to narrow down the field. This just generates a lot more work for the poor buyer who then has to read and evaluate all the responses.
- Functionality is assessed by ‘dog and pony show’ demos (product demos where the vendor shows off the best bits of their software while carefully avoiding the weaker areas) rather than by asking vendors to show how their tool handles scripted use case scenarios.
- Key stakeholders such as Procurement, Architecture and Information Security are not consulted early enough, meaning that relevant standards and policies are not captured as non-functional requirements.
- Vendor implementation experience is not taken into account. And not just the vendor in general, but also the experience of the implementation team members as well. The likelihood of a successful outcome is hugely dependant on the experience of the vendor.
- There is no opportunity for a collaborative (rather than adversarial) relationship to be formed with the shortlisted vendors. Similarly, when price negotiations are seen as a zero sum game, where the vendor is there to be screwed on price, a productive ongoing partnership is unlikely to ensue.
- Insufficient effort is made to determine realistic ongoing costs. Unfortunately, in a competitive situation, vendors are unlikely to fully disclose the realistic ongoing costs (e.g. ongoing config, training, internal resourcing) due to fear of being eliminated from the shortlist for cost reasons. No matter how good the toolset, if you haven’t budgeted enough to operate it, it will fail. A similar pitfall is when the toolset scope is not properly defined in the first place, resulting in unbudgeted costs being incurred to customise the toolset to do things that were not defined within the original scope.
- The vendor is relied on as the only/main source of reference sites instead of user groups, forums, peer networks and Google. These ‘unofficial sources’ are the best ways to learn about the vendor (implementation experience, likely quality of relationship, ability to support you), toolset strengths and weaknesses, and realistic implementation and ongoing costs.
- A spreadsheet, chock full of weightings and complex formulas, is used to reduce each vendor/toolset to single score, thereby making the final decision for you. A spreadsheet is there to assist you in making a good decision not to make the decision for you.
If you’re not an expert in ITSM toolset selection, do consider getting external help. A buyer’s advocate will help you keep the process on track, reduce the administrative burden, ensure independence and help you avoid pitfalls such as the ones above.