I’ve seen many ITSM toolset implementation failures. Usually they happen because the buyer wasn’t particularly diligent during the evaluation and the decision was made on little more than a vendor’s dog and pony show – you know the one, the one where the vendor’s slickest salesman shows you all the flashest features of the software, fails to point out its shortcomings, and dazzles you with the all the wonderful stuff that’s slated for a yet-to-be-determined future release.
And even when functional requirements are properly evaluated (here by the way is a good starting list to get you thinking: Functional requirements by process for ITSM software), important non-functional requirements are often overlooked and this can spell trouble down the track, e.g. the software is great but the vendor can’t provide the level of support you need.
To help you avoid experiencing one of these failures first hand, here are some questions you should ask yourself and the vendors before choosing your shiny new ITSM software:
- What is the total cost of ownership of the tool being considered? Consider licenses, infrastructure, installation/configuration, data migration, ongoing support & maintenance, enhancement costs (initial & future), training, future upgrades.
- What internal resources will be required to assist with the implementation?
- After the implementation, what sort of vendor assistance is free and what is billable?
- After the implementation, what rates are used for any billable vendor assistance?
Functionality needed today
- What does your current tool do well? Will the ITSM toolset being considered do these well too?
- What don’t you like about your current tool? Is the toolset being considered stronger in these areas?
- What do you need the tool to do right now? (E.g. support response and resolution SLAs, segregate service requests from incidents; self-configure incident, problem and change workflows, ad-hoc reporting). To what degree does the tool meet these requirements? Ideally, you should separate ‘must haves’ from ‘nice to haves’ – any software that can’t meet all of your must-have requirements should be dropped from your shortlist.The degree to which each ITSM toolset meets the ‘nice to haves’ provides a way to compare the relative strength of each toolset being considered.
- What do your customers need the tool to do right now? (E.g. Log and track incident and service requests online). To what degree does the tool meet these requirements?
- What sort of configuration/changes within the toolset can you do yourselves and what sort of configuration/changes will require assistance from the vendor?
Functionality needed in the future
- What will you need the tool to do within the next 2 years? To what degree does the tool meet these requirements today? Thinking beyond Incident, Service Request and Change Management now will save a lot of time and possible pain later, e.g. consider Problem Management, Release Management, Configuration Management, Service Catalogue Management, Knowledge Management
- What is the product roadmap of the tool being considered? (I.e. what enhancements and features are planned for release and over what timetable?)
If the service is hosted:
- How are the data (at the data centre) and transactions (between the browser and the data centre) secured?
- What are the service availability guarantees and how is ‘availability’ calculated?
- What are the user experience guarantees (e.g. page load times) and how are these calculated?
- In the event of a disaster, what are the Recovery Time and Recovery Point Objectives?
- During what days, times can you contact support?
- What are the incident priority definitions, including response and resolution times?
- What are the incident response and resolution performance targets (percentages)?
- Are you able to talk to the vendor’s account representative during your own working hours? (E.g. to escalate a service issue, or discuss an enhancement request).
- What support channels are provided/available if you have issues or questions with the toolset once implemented? (E.g. telephone, email, web portal).
- What are the penalties associated with failing to meet the agreed Service Levels?
- What is the mechanism for tracking and delivering bug fixes?
- How will you be made aware of relevant bugs reported by other organisations?
- Can the vendor provide you with a list of existing problems/known errors?
- Is there a local User Group? How often does it meet? How many customers typically come along?
- How do you know that the vendor is going to be here to support you in the long term?
- Will the two organisations (yours and the vendor) fit culturally? E.g. if you expect a bit of give and take when it comes to billing, there can be a problem when the vendor wants to charge for every second spent on the phone.
- How many similar implementations has this vendor done?
- What ITIL, toolset and implementation experience do the vendor’s consultants have? (in particular, the consultant(s) that would be involved in your implementation).
- When can the vendor start work?
- How long is the implementation likely to take?
- What one-off (implementation) and ongoing training is available?
- If the vendor provides face-to-face training, what training qualification(s) do their trainers have? (E.g. Certificate IV in Workplace Training & Assessment)
- What other local organisations (same city, same country) are using the tool being considered?
- Which organisations, of those who are using the tool, can you have ‘warts and all’
- Who can you talk to that has evaluated the tool being considered and chosen another product? (It is useful to know why others have chosen to use an alternate toolset and why).