How to Replace an Aging Ticketing System

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!

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 are on-premises 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 seven-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 include the following:

• 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 system, what it does right, what’s wrong with it, and how much it is 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, do another baseline and see how the new system 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, Should Have, Could Have, and Would Have). 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 LinkedIn, other 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, along with your SOR, to the “short list” of potential suppliers (the top three to five, 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 SOR. 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 two to three vendors.
• Get ready to negotiate. 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 ongoing 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 two to three 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, you want 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 it’s 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-Step Process for Leading 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 online, celebrate and promote that success story. This approach 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 to 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.

Realize going in that implementing a new ticketing system involves not just changing a system, but also the people and processes connected to that system. Thus, it should be handled as a significant organizational change in your support center—one that must be managed and executed carefully. A step-by-step process approach as outlined above will minimize risk of failure and maximize the likelihood of success.

Implementing a new ticketing system involves not just changing a system, but also the people and processes connected to that system.

Once the major capabilities of the new system are up and running, celebrate your success and congratulate your team and all those who were supportive during the roll-out. Business and technology change is a fact of life today, so keep the momentum going by ensuring you have a small cross-functional team to monitor and ensure ongoing maintenance and continual improvement of the system, process, and people involved.

Paul is the president and principal consultant of Optimal Connections LLC. With more than 30 years of experience in planning and managing technology services, Paul has held numerous positions in both support and management for companies such as Motorola, FileNet, and QAD. He is also experienced in service desk infrastructure development, support center consolidation, deployment of web portals and knowledge management systems, as well as service marketing strategy and activities. Currently Paul delivers a variety of services to IT organizations, including Support Center Analyst and Manager training, ITIL Foundation and Intermediate level training, Best-Practice Assessments, Support Center Audits, and general IT consulting. His degrees include a BA and an MBA. Paul is certified in most ITIL Intermediate levels and is a certified ITIL Expert. He is also on the HDI Faculty and trains for ITpreneurs, Global Knowledge, Phoenix TS, and other training organizations. For more about Paul, please visit www.optimalconnections.com.