Successfully Replacing an Aging Ticketing System
How to Avoid Problems and Ensure Success!
So you are looking to replace your aging ticketing system. I have been the project lead to replace such a system and have successfully carried out the task – and I can tell you it can be a daunting job!
Please note: you want to follow best practices on this project, selecting the best quality system for the lowest price that Meets Your Needs (and that is very important). Remember that there are probably a thousand ticketing systems out there, from free GNU products, to more expensive systems. The features and functionality all vary, along with the non-functionality aspects (flexibility, ability to scale, ability to integrate, etc.). Some are Saas, others on premise software and technology. Some are feature rich, others less so.
A word to the wise: do not be “tool driven” – be strategy, process and ROI driven. As a consultant I have also helped a major medical care organization select a replacement for their aging ticketing system. At the time they had a 7-year-old system that had gone through lots of customization, to the extent that it could no longer be updated, or effectively maintained. It could no longer be integrated with other new support systems, due to the lack of interface capability. It was failing regularly, impacting service and support provision, and the organization’s performance as a whole.
There is a step by step process for the selection process described in the ITIL books, but essentially the best-practice steps for going about this sort of project are:
- Determine where you want to go with your new system – what is the vision? Draw input from your executives, support group managers, and other stakeholders.
- Capture where you are now – do a baseline assessment of your current systems, what it is does right, what’s wrong with it, and how much is it costing you. Meet with all groups that are using the present system and do a survey of their requirements – get their input on what they want from a replacement system. This gathers valuable input for your requirements document and builds “buy-in” and support for the system later on when you implement it. Capture a baseline of performance metrics (KPIs) on the current system – average resolution time, response time, customer and user satisfaction, percentage of escalations to tier 2, etc. After you install the new system and give it a few months, you ought to do another baseline and see how the new systems has improved support center performance!
- Document ALL of your “needs” in a Statement of Requirements (SOR) document. This includes functional as well as non-functional requirements, process support needs, budgetary requirements, etc. This will serve as your objective “measuring tool” by which to judge the several proposals that will be submitted to you.
- Be sure to prioritize or rank your requirements, in terms of what’s most important, somewhat important, a nice option, and least important (I use the MOSCOW approach in requirements documents to note what’s important – Must Have’s, Should Have’s, Could Have’s, and Would Have’s – see attached SOR example). If you provide no SOR document to your potential vendors, they will most certainly supply you with their own statement of requirements (and you can be sure it will be biased toward their particular solution).
- Based on your requirements, research who the top vendors are in the industry that could potentially meet your requirements. Research other organizations similar to yours in your industry sector – what are they using? Don’t be afraid to contact people through Linked In, or social media, or email, and ask them for feedback on their experiences. Be as informed as possible before meeting with vendors.
- Send out your RFP (Request for Proposal), along with your SOR, to the “short list” of potential suppliers (the top 3-5, for example), and be sure when you send this out, it includes how you want them to respond (you want all their responses in the same format, for easy review and processing, so tell them how to organize their responses into a binder).
- Manage this as a project. Get their return proposals and evaluate them in accordance with your RFP and Statement of Requirements. This is where you are comparing proposals that are formatted in the same way, and you are looking at their cost-effectiveness of meeting all the requirements in your SOR document – general requirements, function requirements, and non-functional requirements. In most cases, none of the vendors will meet every single one of your requirements. But a potential vendor should meet ALL of your mandatory requirements, all of your “must have” requirements, and a good part of the “should have” requirements. This will provide you with a basis to select the top 2-3 vendors.
- Now comes the negotiation stage. You need to plan on using your negotiation skills at this point, so that you get most of what your requirements have listed, for the best price (the best ROI). Keep in mind that you should use some financial tools for this, as the best price is not always the one you pay lowest for up front. There are initial up-front costs, and on-going costs. Likewise, benefits accrue initially, but also over the life of the investment. Generally speaking, you want to minimize up-front costs, and realize benefits (or pay-back) as early as possible. To assess cost across the 2-3 options, use a Total Cost of Ownership (TCO) approach (spreadsheet tools are available for this) over the expected life of your system. Also calculate projected ROI of the various options, and at what point you would “break-even” and begin to reap financial and other benefits from the system. Focus on the best quality system that meets your needs, with the lowest cost over the life of the investment. In other words, the system that delivers the most value and ROI.
- After selection, you will enter the implementation stage – this is where you continue to manage this as a project but shift into a new phase. Be aware that you need to look at this as a “systems implementation” – consideration of people, processes, and technology all must play a role in implementation. Have a good project plan, a skilled project manager, and a cross-functional project team (for buy-in from other groups) to drive the implementation. In many cases a system implementation such as this can be considered a “big change”, or what we call Organizational Change. It’s a good idea to manage this as an organizational change, as its going to impact the “organization” – and the organization (people, processes, and even culture) will have to adjust as you implement the new system. For additional guidance, see “Kotter’s 8 steps for organizational change”.
- Celebrate early successes during your implementation via email, with stories, photos and interviews. Since you are building on the “buy-in” that has already taken place through your surveys and initial research, start your success story series with promoting your implementation team, and who will be a part of this. When you install and configure the system, record interviews and celebrate that. As the initial modules comes on line, celebrate and promote that success story. This will build excitement, support and momentum for the project as stakeholders see and hear about the successful new system (as these systems can take weeks, and even months for the entire roll-out, it’s important to have a communication plan, and keep everyone informed!).
- Once you have the major features and functionality up and running, after a few months do another baseline assessment on performance to key support center metrics (KPIs), comparing your new numbers with the initial baseline assessment numbers. You should see a positive change, and this should be reason for further celebration, and underscore the success of the project!
- Keep the momentum going by putting in place a supporting cross-functional team, to monitor the performance of the system, address any issues that come up, function as a technical liaison to the vendor, and report the positive impact the new ticket system is having on a regular basis.
Paul M. Dooley
Optimal Connections, LLC
HDI Instructor, Auditor and Consultant
ITIL Expert and Instructor