In September 2016, at the birth of the ITSM.tools website, I wrote a blog about the continued high levels of IT service management (ITSM) tool churn and outlined what I see as the main reasons companies change tool. In addition to my 25 possible reasons, I also included a one question poll asking – What was the main reason for your company changing its ITSM tool? – with ten possible answers (which were boiled down from the original list of 25 reasons) as follows:
- Old tool failed to deliver the expected benefits
- Liked the look of an alternative tool/convincing vendor marketing/industry hype
- Corporate cloud strategy/a larger transformation project/senior employee dictated it
- Multiple service desk and tool rationalization project
- New ITSM process adoption required a new tool, including enterprise service management support
- Tool dissatisfaction related to: ITIL-alignment, usability, manual activity, flexibility, or customization
- Dissatisfaction with vendor support and/or relationship
- Excessive costs related to maintenance fees, admin effort, or upgrading the existing tool
- Tool was end-of-life or simply outdated/a homegrown ITSM tool was no longer workable
- Other (please state)
The survey results
The survey is still open but I’ve taken a snapshot, based on 212 responses, to create this blog:
|Reason for changing ITSM tool||Share of Vote|
|1. Tool dissatisfaction related to: ITIL-alignment, usability, manual activity, flexibility, or customization||18%|
|2. Old tool failed to deliver the expected benefits||17%|
|3. Tool was end-of-life or simply outdated/a homegrown ITSM tool was no longer workable||12%|
|4. Corporate cloud strategy/a larger transformation project/senior employee dictated it||10%|
|5. New ITSM process adoption required a new tool, including enterprise service management support||10%|
|6. Excessive costs related to maintenance fees, admin effort, or upgrading the existing tool||10%|
|8. Dissatisfaction with vendor support and/or relationship||5%|
|9. Multiple service desk and tool rationalization project||5%|
|10. Liked the look of an alternative tool/convincing vendor marketing/industry hype||4%|
Tool dissatisfaction wins (if you can consider it winning)
The two top reasons for tool churn are similar – the current tool was unfit for purpose – and make up a third of responses:
- Tool dissatisfaction (18%)
- Old tool failed to deliver the expected benefits (17%)
So, the current tool just didn’t deliver against customer needs and/or expectations. Something that could be related to a number of root causes, but with the blame hard to pin down:
- The tool not keeping up with industry trends (and needs) – a vendor product strategy and management issue
- The customer choosing the wrong tool relative to needs – a customer issue, albeit driven by the unfortunate industry penchant for reusing third-party request for proposal (RFP) templates
- The professional services employed in implementing the tool, process redesign, and effecting people change missing the mark – which could be either customer-investment or vendor-capability influenced (or both)
The third highest response is also somewhat related – tool was end-of-life or simply outdated – especially in relation to the first root cause above.
Vendor marketing actually plays a very small role in ITSM tool churn
At the other end of the spectrum, only 4% of respondents stated that they were lured away from their existing tool by the new tool vendor’s marketing or industry hype. This makes sense, and is somewhat of a relief – that vendor marketing most likely comes into play after the decision to change ITSM tool has already been made. It’s also an important point for vendors to note – that their marketing investments should be driving choices re a new-tool decision rather than the initial decision itself.
ITSM tool churn isn’t focused enough on pushing things forward
The fourth and fifth high-scoring options can also be grouped together, in that they both relate to something bigger than the status quo – driven either by corporate IT strategy or the desire to do more in terms of better service management/delivery. But at just a collective 20% (or 25%, if position nine is included too) it speaks volumes to me as to how we are or aren’t pushing service delivery and support forward in the context of wider IT ambitions and business needs. That we’re possibly still too focused on what we do (with ITSM) over what we achieve through what we do. Perhaps the ITSM version of rearranging the deckchairs on the Titanic.
ITSM tool vendor dissatisfaction isn’t the real issue
Finally, we’re left with options six and eight – dissatisfaction with costs and vendor support/relationships – which falls firmly at the feet of ITSM tool vendors. And, to be fair, this is probably lower than other industry surveys have previously conveyed. My best guess, OK educated guess, is that this is due to the increased take up of the software-as-a-service (SaaS) delivery model for ITSM. With support and maintenance costs now hidden within the monthly subscription, rather than a 20-22% annual levy, and vendors more focused on relationships given the ease of migration from one SaaS solution to another (potentially with a minimal cost impact).
Of course, we can’t ignore the dissatisfaction with the tools themselves – which customers would argue falls firmly at the feet of the vendors. But how much of this dissatisfaction is really related to the tool rather than the implementation of, and proactivity in using, the tool? It’s just so hard to ascertain – as customers will blame the tool (and vendors) and vendors will blame the customers (as, for example, a bad driver might say that a supercar is a poor excuse for a car).
I don’t think that we’ll ever get to the true root cause and instead all parties just need to manage the inherent risks better – where companies need to choose a tool that meets their needs and then ensure that the required people, process, and technology changes are considered and addressed as a singular investment to improve IT service delivery and support.
What do you think of the results? Are they as expected? How would you alternatively interpret them?