Jarod Greene, VP of Service Management Strategy at Cherwell Software and former Gartner IT service management (ITSM) industry analyst, shares six considerations to keep in mind before switching to a new ITSM tool. With more than 12 years of ITSM industry experience, Jarod understands the market from the vendor, end-user, customer, and analyst perspectives. He’s published many white papers and research articles, and his proficiency in IT service support management processes, organizational structures, and technology is sought after for speaking engagements, customer consultations, and product development.
Stop me if you’re heard this before, but on average, IT organizations replace their ITSM solution once every five years.
Compared to other types of enterprise software, that’s an incredible churn rate. It’s rare to hear about an organization replacing their CRM or ERP solution that often, but this high attrition level is very common in the realm of ITSM. From our vantage point, speaking with many IT organizations regularly, we see that ITSM solutions aren’t replaced because they lack certain features or functions, but rather for reasons that existed at the onset of the tool’s acquisition. In some cases, the ITSM tool was never scoped properly. Or perhaps it was implemented poorly. Perhaps it was purchased for the wrong reasons. Or the IT organization had ineffective processes to begin with, and the ITSM tool just automated those processes.
Tweet this: What should you consider before you think about switching your ITSM tool
Understanding all the things that a new solution can do for you is easy. But while it may seem like you’re making a simple technology switch, it’s important to remember that ITSM replacements are major projects, and the execution of the solution is often part of a larger, more complex infrastructure and operations improvement initiative. Success—or failure—is magnified across the entire IT organization.
Making the right choice is just as important as delivering the solution on time, within budget, and with a high level of quality. Your initial steps need not focus on long and detailed analysis, but rather on producing a document that outlines the parameters of the project and the expected outcomes. Start that document by asking the following questions amongst key stakeholders to deliver your ITSM replacement project faster.
1. ITSM Basics: How are we doing?
This might seem like an obvious question, but knowing the number of incidents, problems, requests, and changes your organization generates and supports on a daily, weekly, or monthly basis can be telling. If you can capture this information, ask if there are IT or business drivers that would cause a change in the current volume? If you can’t capture this information quickly or easily—that’s telling as well! For organizations who can gather the basics, frame your question on a scale and ask, ‘how mature are we now, and how mature do we plan to be in the next 36 months?’ Your response will help you scope your ITSM requirements and ensure your solution can scale to enable additional capacities and integrations as your organization matures.
2. The Business Case: Why do we need a new ITSM tool?
Determining if your current tool is capable of supporting your future state can be difficult, particularly if getting the tool over the hump requires development, training, or services. Measuring the benefits of those efforts against the short and long term costs of the project can quickly get into the weeds, but it is necessary a necessary exercise just the same.
3. ITSM Scope & Objectives: What are we trying to accomplish?
Often, we see ITSM tool implementations go awry because stakeholders have different priorities, and IT and business priorities change during the project. Knowing and documenting what is, and what is not, in scope for various phases of the project is critical, as deviation from the project plan will cause significant overruns. Identify the teams and processes that are in scope, and provide clear documentation on roles and responsibilities. Identify the sponsor, the project leader, owners of the processes that will be affected, and tool owners up front, and engage them early in the process. Their buy-in and support is critical.
4. ITSM Budget: What is the budget for this project?
If the project is funded, know to what degree, and establish a range to encapsulate licensing, services, and any additional training or support resources that may be necessary for a new solution. Because there are so many ITSM solutions to choose from, finding a tool within your budget won’t be difficult, but measuring the ongoing total cost of ownership against the expected return on investment can be.
Know if this will be a capital expenditure or operational expenditure, and try to gather an understanding of your budget for support and maintenance over the next five years. Capture information about vendor licensing and deployment models, the ability to change those over time, and the costs of add-ons and integrations up front as much as you can—these costs can vary widely! Lastly, don’t forget to document adjacent IT and business dependencies, such as competing projects or other factors that may constrain resources and budget cycles.
Tweet this: Setting clear goals and measuring success is a crucial step when considering an ITSM vendor
5. ITSM Outcomes: What will a successful project look like in 18 months?
Measured against your current baseline, define what success will look like in the not-so distant future, in terms of performance metrics and business results. Will you achieve a lower Total of Ownership (TCO), or higher customer satisfaction? Start from the end date and work backwards to better outline what key performance indicators need to be tracked and reported on, by whom and when, and articulate what measures of improvement you can expect. Note that in 12 months, leadership will ask how the project has delivered—you want a better answer than “it’s going well,” with no quantifiable data to back up your claim!
6. Proposal Review: Who is ultimately accountable for selection of the ITSM tool?
Again, what might seem like a no-brainer needs to be articulated so that it’s clear how the selection process will work. If procurement dictates an RFI is required before an RFP, think through how you can work with existing materials or templates to speed the process up. Determine who has the ability and authority to add requirements and begin to map your “must haves, should haves, could haves, won’t haves” (MoSCoWs). Outline the members of the team who will see vendor presentations and demos, and know if you intend on meeting with and contacting customer references. These activities can be time consuming later—plan for them early.
Ultimately, your ITSM project will succeed or fail based on the steps you take before a single vendor demo takes place or proposal be evaluated.