Looking to invest in a new help desk, service desk, or IT service management (ITSM) tool? Where do you start?
In my experience, there’s always the temptation to be led by the market, to see what’s out there and to become bewitched by the functionality offered by the hundreds of ITSM tools available in today’s still-growing tool ecosystem. With this approach, the likely result will undoubtedly be that the selected ITSM tool is merely the one that offers the most bells and whistles for your money, and probably for a little more money, rather than the one that best fits your company’s operational needs.
So what should you do instead? Here, I offer up my tips. If you agree or disagree with them, I’d love to know. Oh, and if you find less humor in here than my usual blogs, it’s because selecting any new technology is a serious matter.
Selecting any new technology is a serious matter.
1. Don’t Start with a List of the Available ITSM Tools
Some people might tell you to start with the latest Forrester Wave or Gartner Magic Quadrant as a long list (rather than a short list). These will help, eventually, but in my opinion they shouldn’t be your first port of call. Instead, start closer to home by understanding what you actually need to achieve.
Now this might be going back to basics, assessing what you need for optimal IT service delivery and IT support, or it might merely be deciding upon the ITSM processes you need to support. So it could be relatively easy. Take your existing processes and consider how they could be improved upon through the use of more modern, fit-for-purpose ITSM technology.
If, however, your various IT operations activities are not aligned to, or expressed in terms of, ITSM best practice, then you’ll most likely need to undertake some form of process maturity assessment. This could be an ITIL assessment or an alternative. If this is the case for your organization, you should probably opt to look at only a few processes in detail to start with, so as not to have unrealistic ambitions of increased ITSM maturity and tool utilization. But there’s no reason why you can’t create high-level requirements related to what you would like to do or to achieve, in terms of additional processes and tool utilization, in the future.
2. Aim for a Single Corporate ITSM Tool and Consistency of ITSM Processes
The selection and purchase of a new ITSM tool is a great opportunity to consolidate things—whether multiple service desk teams, multiple tools, or variant processes. If appropriate, first ensure that the ITSM tool project sets out to accomplish more than just buying another piece of technology and adding to the associated technology management overhead.
Second, ensure that the initiative gets executive or senior management approval not only for the new tool spend but also the consistent utilization of processes throughout the organization. This might be, for example, not only the establishment of a single corporate IT service desk but also a single corporate change management process for all IT-related changes that straddles both run the business (IT ops) and change the business (app dev) activities.
3. Be Clear About Which ITSM Tool Requirements Are “Must Haves” and Those That Are Merely “Nice to Haves”
Any process design work you undertake will form the basis for a new toolset’s features and functions requirements. And it’s important you divide these requirements between those that are must haves and those that are merely desirable.
Once agreed upon, these must-have requirements should not be compromised in favor of any other requirements, especially when based on the goal of getting more for your money. Sadly, this is the proverbial quantity over quality dilemma—the ITSM tool selection equivalent of asking the wrong questions and thus getting the wrong answer—i.e., a tool with lots of capabilities that you’ll probably never use (but of course you’ll still be paying for them).
Plus, tool vendors with products that don’t meet all of the must-have requirements might try to convince you that some of your must haves or mandatory functionality is not really necessary. They might be right, but they might not. Stay focused on what you wish (and need) to achieve, and ensure that people and process needs continue to drive the technology requirements rather than the other way around.
4. Don’t Let Integrations with Other IT and Business Systems Be an Afterthought
When specifying ITSM tool requirements, an organization must consider their current and future needs for integration with other corporate systems. Plus, now that the use of cloud service providers and the service integration and management (SIAM) approach are more popular, there is also the need to integrate to third-party IT systems.
If multiple, non-suite ITSM tools are being considered as a solution, then this also includes the integration between different tools and processes, for example integrating a third-party CMDB with the tool or tools for incident, problem, and change management as a minimum.
Plus, don’t undersell the importance of the ability to easily integrate the tool with existing IT management tools—from the submission of monitoring (or event management) data to the ticketing system through to network discovery data auto-populating the CMDB (if these activities are not part of the new tool).
Finally, the integration requirements must also be created with the future in mind. So look at the tool’s API approach and the number of available pre-built integrations to common IT management and business applications.
5. Weigh Your Requirements Appropriately
All your ITSM tool requirements should be prioritized, using a suitable weighting system. For instance, you can make each requirement group a percentage element of 100 percent so that some requirements count more than others, or you can use multipliers so that some scores count double, triple, etc., which factors in the importance of each process and activity. Thankfully, since many, if not all, tool vendors have used ITIL as a blueprint for the creation of their ITSM product, most modern ITSM tools will deliver against the key elements of the most commonly asked for ITSM capabilities.
Some requirements will be straightforward, such as the nuts and bolts features needed to support the incident management process. Other will not be, especially elements related to the ITSM tool as a whole rather than individual processes. For instance, requirements around ease-of-use can be subjective and multidimensional—where a tool that’s very easy to use on a day-to-day basis might not be so easy to configure and customize. And don’t forget the scoring of attributes related to reporting; workflow, automation, and notifications; and security—where a prospective tool might meet all the ITSM-related requirements but fail to meet mandatory, governance-related criteria.
6. Score ITSM Tool Vendors Beyond the Offered Tool Functionality
This includes obvious vendor capabilities such as how they are able to assist with more than just the core ITSM technology need, such as assisting with the people- and process-based changes associated with the introduction of the new tool. So do they have proven methodologies and accelerators to deliver the new technology, plus the required organizational change, successfully and at a rapid pace?
However, your organization might want so much more than a new version of the status quo. You might want to improve ITSM capabilities and maturity, both within already-adopted ITSM processes and with the introduction of new ones. So how will the tool vendor help to up your organization’s ITSM game? Will they be able to assist in the delivery of new best practice processes, tweaked to suit your organization’s peculiarities?
Plus of course we have other requirements to score in addition to process support, such as integrations and interoperability, technical requirements (e.g., performance, security, and resilience), supplier background, implementation parameters (including training), and support and maintenance arrangements. But another important requirement is easy to miss, which leads me to my next tip.
7. Assess ITSM Tool Vendors from a Relationship Perspective
This might seem like a strange thing to state, so stop for a moment to think back to the issues you’ve had with previous tool vendors and their products. The issues might be varied, but I’d be willing to bet that many of them stem from the lack of a relationship, or a very limited relationship, often merely financial, between seller and buyer.
It’s a common complaint from ITSM tool customers, with relationship now second only to support in customer frustrations with tool vendors according to Service Desk Institute (SDI) research. ITSM needs, and the technology that supports them, are complicated and require more than a single business transaction where the customer’s money is exchanged for the vendor’s ITSM tool (or a payment schedule set up for the contract duration for SaaS). And it also requires more than a one-time project to get the technology up and running.
So use both formal and informal channels to understand how the tool vendors being considered build and maintain relationships with their customers. To want such a relationship is not an excessive demand of a vendor, especially in the days of SaaS-delivered ITSM when it’s so much easier to walk away and start again. In fact, smart tool vendors will be wanting a relationship with you.
8. Let the Real Users of the ITSM Tool Play a Key Role in Tool Selection
So a prospective ITSM tool looks great on paper (or on your screen), scoring highly across the board. But you’ve been to this rodeo before. You thus require a proof-of-concept to see the tool working in the wild and not just in the hands of the seasoned vendor demo person.
Such a proof-of-concept, if well used, can make or break (sometimes literally) a tool for your organization. And at this point, it’s important to allow the real users to get their hands dirty. Importantly, these days, this is not just IT staff, as some functionality, such as self-service and self-help, will require appropriate end-user use and feedback.
IT staff in particular will need to be provided with very focused evaluation criteria to almost-scientifically rate each tool rather than just being allowed to be subjective, for instance stating, “There was something about it I didn’t like.” These criteria should include intuitiveness and user-friendliness, the speed of time-critical activities such as incident logging, and the breadth and depth of reporting capabilities, among others.
So there you have my eight tips for ITSM tool selection. What would you argue with or add to the list?
Who is Joe the IT Guy? A n
ative New Yorker. Loves everything IT-related (and hugs). Passionate blogger and Twitter addict. Oh...and resident IT Guy at SysAid Technologies (almost forgot the day job!).