As discussed in our previous blog, ITSM tool use and replacement landscapes are changing all the time. Either organizations are using the same tool for years, or they are stuck in a "merry-go-round", changing their tool every few years because each one doesn’t deliver on its promises.
In the IT Service Management (ITSM) community, there seems to have been a long history of ITSM tool “bashing.” If things don’t go to plan – it’s the tool’s fault. If we can’t achieve a particular target – it’s the tool’s fault. And I could easily go on with issues blamed upon the ITSM tool.
Then there might be tool discontent in terms of:
Missing process-supporting capabilities
The complexity and difficulty of use
The time it takes to undertake what should be simple tasks
The quality of available reports
The low uptake of self-service and knowledge management capabilities (and the impact this has on the expected financial benefits)
However, when the ITSM tool is blamed (for a failure to meet a desired outcome), or if there’s dissatisfaction with the tool’s “capabilities,” is it always the tool’s fault?
“Always” is a Bad Word but It Has a Good Use Here
When you are asked if, or state that, it’s “always the tool’s fault” it’s very had to give an honest answer of “yes.” Why? Because the tool can’t logically be blamed for absolutely everything (especially if your organization had previously replaced an unsatisfactory tool). And hopefully this is enough to get you, and your organization, questioning how many of the ITSM-tool issues you’re experiencing really do stem from the tool itself.
It also begs two other important questions:
Are many of the encountered tool difficulties the real issues or are they merely the symptoms of a different root cause (or multiple causes)?
What’s the real business impact of highlighted issues (such as the ones listed above)?
Starting with the second of the above questions, how are the highlighted ITSM-tool issues impacting business operations and outcomes (over and above the impact on IT operations)? For example:
Missing process capabilities might mean that what were intended to be ITSM best practice processes are actually suboptimal. Or they still include an unnecessary level of manual, or third-party tool, operations which ultimately costs at both an IT and business level.
Difficulty of (tool) use might prevent people from using the ITSM tool as much as they should. This firstly means that the investment has been suboptimal, and secondly there will ultimately be an associated (financial) business cost, whether additional staff costs or the adverse impact of prolonged downtime, for example.
Issues with the available reporting capabilities might mean that manual-reporting activities add cost and time to the process and – more importantly – problems and improvement opportunities with operations and services might go unnoticed.
Ultimately, it’s important to raise the conversation of what’s “wrong” with your ITSM tool from the features to the resulting business impact.
ITSM Tool Dissatisfaction Symptoms Versus the Root Causes
There are a variety of reasons why organizations want/need to change their ITSM tool (and perhaps then change it again). Many of these reasons are considered to be tool related, for example:
Dissatisfaction with tool capabilities in the context of one or more of: ITIL-alignment, usability, the high level of manual activity, or the flexibility/ability to change
The failure to deliver the anticipated benefits – from capabilities, through tool usage, to the realized time/cost savings
The tool was end-of-life or simply outdated relative to newer tools (and their capabilities)
These all sound plausible and legitimate reasons for wanting to change ITSM tool – but how many really are the tool’s fault? There’s a need to separate the real (root) causes from the visible symptoms (where the tool is “blamed”).
For instance, is the lack of current-tool use (by IT staff) merely a symptom? With the real cause(s) perhaps more likely to be an organizational issue such as poor implementation planning, design, and delivery, or the absence of organizational change management during its delivery – i.e. it’s not that the tool can’t do something as needed but rather that the way it has been introduced is such that it’s highly unlikely that it can be used as needed.
Importantly, it needs to be understood that merely changing the current ITSM tool for a new one – and doing nothing differently – will probably change little and leave your organization in the same dissatisfied state.
Ultimately, it cannot be assumed that the ITSM tool itself is always at fault.
Understanding the Possible Root Causes
The real reasons for the issues with your current ITSM tool, its use, and the associated results it helps to deliver may be complex. However, this is not excuse for looking beyond the tool itself – and the visible symptoms – to identify the real root causes of why things aren’t as you would like, or need, them to be.
For example, additional potential (root) causes of tool dissatisfaction could include:
The use of a mis-focused set of business requirements during tool selection, such that an ill-fitting tool was procured
The automation of (the existing) badly-designed ITSM processes
Insufficient IT staff to actually do what’s needed
Deeper cultural issues that inhibit or prevent collaboration and knowledge sharing
And these non-tool-related causes (of dissatisfaction) will not be addressed by merely replacing your IT organization’s ITSM tool.
Of course, sometimes the tool will be at fault – with it simply unable to meet the needs and ambitions of your organization. But when looking to change ITSM tool, to something more in line with your organization’s wants and needs, it’s critical to truly understand what previously “went wrong” as well as knowing what else is needed from a new tool. It’s important to have the right conversations.
To understand the topics discussed in this article in more detail, you can register for our on demand webinar which we are hosting alongside ITSM.Tools’ Stephen Mann.