Upgrading a major software application can be challenging. Many factors come into play, including budget issues, downtime, upskilling the staff, and addressing software and automation dependencies. If you are trying to decide on whether or not to upgrade your enterprise software or to replace legacy software that no longer has solid value, this post is for you.
The drawbacks of technical debt
“Technical debt” is the cost to an organization of leaving some technical inadequacy unchecked. Sitting year over year with outdated software that doesn’t meet your business needs can have long-term effects that include insufficient security, unpatched product issues, and lack of features found in more contemporary applications. It can create more work for your resources, stall your team’s skill set over time, and bring down overall morale amongst the staff. And it is very costly.
InformationWeek estimates that U.S. IT wastes $85B annually on bad tech rather than buying or building better software. And this doesn’t account for other teams in your company that might be contracting separately with vendors for a more robust option.1
Gartner predicts that by 2025, 40% of IT budgets will be spent on maintaining technical debt.2
So, ask yourself – Are you unhappy with your current software? How long has it been since it was upgraded? Are your users getting the most out of the product? Before deciding on a move from one application to another, you might want to tally your responses to a few other questions:
- If it has been a while since you upgraded, have you looked at its latest features to see if these fill the gaps in your expectations? For instance, does the newer version include automation or use AI to make your team’s job easier? If the software is still lacking, have you spoken to your software vendor about what is on the product roadmap, and if you can be part of that decision making process (i.e., would they allow you participate on an advisory board or sponsor new features with their development team)?
- Are you already using different products that essentially do the same thing in order to accommodate other teams/departments/etc.? If so, can the same desired functionality be met by your existing software after an upgrade or by replacing it with something better on the market?
- How costly is it to maintain your current software (e.g., hardware, resources, vendor costs, etc.) and would that be reduced with an upgrade, relocation, or by replacing it with another product? Does your vendor provide flexibility in installation (i.e., local installation, public cloud installation, private cloud offering, etc.)? Do they have service offerings that make it cost effective to utilize their staff for operational support as opposed to doing it fully in-house?
- If your users have difficulty using the software, is it because it is truly user unfriendly, or do the users require some additional training or guidance? I.e., would their experience truly be different with any other software under the same set of circumstances? Does your vendor offer a robust training program and assistance with SOP and best practice development to further enable your users?
Building out a software upgrade project scope
Once you have compiled your answers to the above, scope out a couple of your best options. Use a trusted vendor to do some of this heavy lifting by giving them your needs/criteria to meet. Then select your most ideal scenario and at least one other alternative that is less expensive and/or resource intensive. This will give you a backup plan if the ideal scenario doesn’t obtain the necessary buy-in.
Break up your project scope to include both what is IN SCOPE and what is OUT OF SCOPE. This will prevent you from trying to account for everything. Be sure to include the basics, like:
- Project goals (e.g., access to contemporary software with improved security and features, more efficient workflows)
- Project deliverables (e.g., latest version of software in production environment; staff training; revised SOPs)
- List of resources (e.g., internal team, vendor(s), infrastructure)
- Timeline
Creating a cost-benefits analysis
With your project scope in hand, start building your cost-benefits analysis. This analysis may include the following elements:
Costs
- Direct labor costs, including any vendor service fees
- Direct costs for hardware or other materials, including any potential costs for a public cloud space or private cloud offering
- Impact on day-to-day activities, such as outages/downtime
- Potential risks
Benefits
- Long-term reduction of costs, like maintenance of old technology, offsetting resources with vendor placed staffing, efficiency gains, etc.
- Increases in production turn-around times or sales revenue
- Improvements to security and overall infrastructure
- Competitive advantage like top-of-the-line software, best-in-class service team, etc.
- Intangible benefits like employee satisfaction
Develop stakeholder buy-in
Compile a list of your internal company stakeholders, like management for the end users, owners of the technology within IT, and your information governance team leads. Include good notes on the value the software brings to them individually, along with their most likely concerns with an upgrade. Reach out to the top stakeholders on this list and ensure their input is included within your project scope.
Prepare to overcome common objections, like preferences for less popular software applications. Approach these objections with leading questions to help identify how your solution will address their overall concerns.
Best software upgrade outcome
While change is not always easy, it is generally a good thing when it comes to tech. By scoping out what you need with a trusted vendor and breaking out the costs vs. the benefits, you will have the tools necessary to make this decision, get buy-in from your stakeholders, and take the next steps.
1 Information Week, 2022. CIOs: Stop Spending on Bad Tech
2 ComputerWeekly, 2022. What are the drivers for application modernisation?
