Much has changed in the world of IT service management (ITSM) over the last few years, and your organisation has likely wondered whether its existing toolset (which might be a “homegrown” ITSM tool) is still fit for purpose. It would not be alone if this were the case, and if so, ITSM tool selection can seem pretty daunting, especially if it’s not that long since the current tool was selected.
To help, this article explains how best to select a new ITSM tool—starting with understanding whether it’s actually (or only) the ITSM tool that’s the issue as the first of eight areas to consider and address in ITSM tool selection.
1. Fully understand the reasons for ITSM tool change
It might be that your current ITSM tool can’t or doesn’t deliver against your IT and business requirements, but is this the only factor adversely affecting your organisation’s service management capabilities?
Before jumping into ITSM tool replacement (which might be viewed as “yet another ITSM tool replacement”), it’s essential to understand whether all of the perceived service management issues relate to the technology. Or whether people and process issues are factors too. Replacing the ITSM tool without addressing these factors is unlikely to address all of the service management issues perceived to come from the previous toolset.
The change in the ITSM tool is also a great opportunity to improve service management capabilities across operations, services, experiences, and outcomes, which in itself can remove issues related to suboptimal ITSM practices.
2. Seperate the symptoms from the root causes
In understanding why your organisation wants or needs to change its ITSM tool, it’s critical to separate the symptoms and the root causes. For example, are the current issues with ITSM tool use merely the symptom, with the actual root causes likely to be issues such as poor tool implementation or the absence of organisational change management (OCM) during its delivery?
The introduction of IT self-service capabilities is a great example of this, where the lack of employee adoption is the visible symptom, but the root causes are likely to include:
- It not being viewed as a people-change project that requires OCM to succeed
- The focus on saving money, not improving experiences and outcomes (which in turn save money)
- Insufficient knowledge management and automation capabilities.
3. Involve all interested parties in the ITSM tool selection process (and from the outset)
This requirement was difficult enough when the ITSM tool only served IT needs. Now, with enterprise service management strategies potentially in play, the spectrum of business stakeholders for the ITSM tool is much broader.
It might be that the new ITSM tool only needs to meet the needs of IT, but this is still a wide range of roles and requirements (and expectations). This range includes the service owners, operational IT management, the roles that will use the ITSM tool “all day, every day”, and the end-users. When this portfolio of roles is extended for the other business functions that currently or will use the ITSM tool – to enable digital workflow automation and other capabilities such as knowledge management and self-service – it also brings the need for greater consistency into the frame. Where organisations ideally build service and support capabilities around employees rather than potentially disparate business function operations.
4. Agree on why a new ITSM tool is needed, not the “capability elements” needed
ITSM tool selection projects have long suffered from focusing on detailed function-and-feature lists. These lists describe the “nuts and bolts” of what’s needed from the new ITSM tool, but this is usually based on what ITSM tools can offer rather than what the procuring organisation actually needs to achieve. It, therefore, focuses on the “means to an end” rather than the “end” itself, where the “end” hopefully relates to a better business outcome of some sort.
So focus on what needs to be achieved rather than the potential functions and features. And don’t use another organisation’s list of ITSM tool requirements to save time, even if they are happy with the results they received using it. The adage “if you ask the wrong questions, you likely get the wrong answers” definitely applies to ITSM tool selection.
Finally, don’t just try to fix your current tool’s weaknesses; focus on what it’s good at, too, because there’s no guarantee that a new tool will also be.
5. Reflect your organisation’s service management maturity in its ITSM tool needs
Your organisation’s “ITSM maturity” level can relate to various things, including:
- The breadth of ITSM process or practice adoption
- The depth of process or practice adoption
- The use of cross-process capabilities such as knowledge management and automation
- How the adopted processes are executed in reality.
These factors can’t be ignored in ITSM tool selection. If only because your organisation will increase tool costs and complexity by buying ITSM capabilities it will never use.
6. Appreciate that not all ITSM tool capabilities are born equal
This point works two ways. First, some ITSM tool capabilities will be more important to your organisation than others, which shouldn’t be forgotten in tool selection. Second, different ITSM tools have strengths in different areas. For example, one ITSM tool might offer industry-leading IT self-service capabilities while its change enablement capabilities are on par with other tools. In contrast, another ITSM tool might offer the reverse.
These distinctions are important when matching an ITSM tool to your required business outcomes, and the request for proposal (RFP) document, if used, needs to differentiate between what a tool offers and what it will actually do for your organisation (in outcome terms).
7. Create an RFP that helps everyone
Everything mentioned so far has brought us to a point where the RFP covers what your organisation needs to achieve – your desired outcomes – rather than whether the hundreds of potential ITSM tool feature points are available.
There are some checklist points for RFP creation that should be born in mind:
- RFP questions should allow tool vendors to explain how their solution will help
- Rise above functions and features to focus on the required IT and business outcomes
- Stay focused on your needs, not distracted by what’s available
- Align your ITSM needs with the “customer” perspective, i.e. the outcome over the process
- Balance current and future needs realistically
- Take the time it needs to make the right tool selection decision, and avoid the adage “act in haste, repent at leisure”.
In addition to asking the right questions, this approach also allows ITSM tool vendors the freedom to explain how they can help you fully. The request for greater detail can also highlight when a vendor isn’t as interested in winning your business as you need them to be.
8. Research the ITSM tool market sufficiently
It’s essential to understand the “sweet spot” of a vendor and their tool, i.e. where they usually win and retain business. So look for information related to the following:
- Customer sizing and key verticals
- Supported geographies, including local support capabilities and languages
- The ITSM maturity fit
- The product roadmap
- Recent market-share growth
- The vendor’s relationships with customers
Hopefully, the above list is a helpful contribution to your next ITSM tool selection project. Ultimately, there’s a need to focus on ITSM tool value, not just costs, and how it delivers against required outcomes and not just the functions and features it offers.
If you would like to find out more about HaloITSM and what makes it the best ITSM tool for your organisation, book a demo by clicking the button below.
