Perhaps you’ve recently implemented a new IT support, or IT service management (ITSM), tool, or you’re simply wanting to assess the suitability of your current ITSM tool before changing it. What’s the best way to go about evaluating its success within your organization?
To help you address that question, here are five pieces of advice:
1. Seek user input
Of course, you can – and should – first ask the people who use it. This includes the service desk analysts that “live in it” as well as the people they support, your organization’s employees. It will certainly offer a lot of qualitative information as to how well the ITSM tool is faring – especially in terms of intuitiveness, ease-of-use, and, generally, how it makes people’s lives easier. But you’ll also need to quantify how much of what you needed it for is being met, and how well.
2. Dig out your old ITSM tool selection RFP
This is, of course, unless you have the time and resources to define your ITSM tool requirements from scratch again. It’s probably not the case, unless you’re actively seeking to change the ITSM tool when measuring your current tool’s level of success.
So, an obvious approach is to assess how well it currently delivers against your documented business requirements. But how is it best to do this? This can be particularly challenging if your business requirements were a very long list of functions and features.
Plus, what the tool vendor says its tool can do might be different from what the tool actually achieves for your organization. For instance, your ITSM tool might have a wealth of incident management capabilities, but your end users are still unhappy with the quality of service and support they receive for IT issues.
3. Move your focus to outcomes
Hence, your real focus should be elevated from the tool itself to consider your service and support success – ideally with the measurement of results and business outcomes rather than the mechanics of tool use.
Rather than the 50+ feature-point requirements that were originally documented in the RFP, such as:
- Are change records created via a formalized request for change (RFC) process?
- Can RFCs be classified based on change category and prioritization?
- Can pre-defined change models be used for pre-authorized, low-risk changes?
You might find this easiest if you transform your RFP into desired-outcome statements. For instance, change management would be something like:
- Protecting business operations from the adverse impact of uncontrolled changes
- Reducing risks and meeting governance requirements when making changes
- Speeding up the delivery of IT and business change
Plus, there’ll likely be newer requirements, and maybe things that were somehow missed from the original RFP.
4. Ignore the background noise
Focus on what’s really important to your key stakeholders (when determining the level of ITSM tool success). So, for instance, using the above change management example, consistently achieving the three desired outcomes will be far more important than traditional change metrics, such as the number of requests for change (RFCs) handled.
For modern IT support teams that are focused on doing what’s right for their parent organization, there are two perspectives that are important to include – value creation and employee experience.
5. Consider whether ITSM tool success can and should be measured in isolation
If you think about the old ITIL mantra of “people, process, and technology” and the newer ITIL 4 change from processes to practices, your IT support success relies on more than the technology. And to claim technology success while your other ITSM-enabling capabilities are subpar is not in the best interest of your organization. Your success will ultimately come from a combination of people, process, and technology.
How do you measure the success of your ITSM tool? Is it radically different from what I’ve outlined above? Please let me know in the social media comments for this blog. And, check out the on-demand webinar: The 5 Key Factors Redefining ITSM Tools and Why it Matters for You.
