When I was working for a fortune 500 company, it always amazed me how easily software upgrade projects were approved. We even built a strategy called “reducing technical debt” that was used to push software upgrades higher in our prioritization model. This wolf in sheep’s clothing model drove us to spend way too much money on upgrades. That money could have been better spent on growing the business if we had looked at the 6 items below.
6 Reasons software upgrades are a bad investment.
- A software upgrade creates no business value. Businesses should focus on upgrading processes.
- Companies do not use measurement to determine what needs to be changed.
- An unknown ROI or ROI less than investing the money elsewhere (ongoing maintenance and upgrade included).
- Planning process is not done or shortened.
- Software is not one size fits all.
- No one shuts off technology.
A software upgrade creates no business value. Businesses should focus on upgrading processes.
Instead of doing software upgrades companies should look at upgrading process or function. For example, when upgrading Microsoft Office, a company should look at whether what they are doing enhances collaboration and roll-out enhanced collaboration processes. Other Office365 functions could include, instant messaging, document sharing and collaboration, video conferencing, team collaboration, schedule delegation and business analytics. If you are looking at upgrading enterprise software, look at rolling out enhanced enterprise processes. For instance, enhanced sales pipeline, inbound sales and marketing, enhanced procure to pay, enhanced order to cash, enhanced record to report, and many other enterprise processes. By breaking a software upgrade into functions and processes you drive easier ways to measure value, train on the changes and ensure acceptance.
Companies do not use measurement to determine what needs to be changed.
If a company does have measures for the processes that are being driven by technology, those measures need to be used to drive technology changes. If process performance is suffering or can be improved then a software upgrade should be considered. While this is not the only measure, it needs to be one of them. Let’s take the Office365 roll-out as an example. Right now, we know that our teams collaborate using email, paper documents and meetings. It has been determined that an average team spends 15% of their time on these activities. Research with Microsoft and other adopters of the team function in Office365 have shown that teams increase efficiency by 25%. The first step to doing this upgrade would be to pilot the team functions with a small pilot group and measure how this impacts their performance. If positive results are seen then the remaining teams should be targeted. By using measurement, we make it much easier to drive value into these decisions.
An unknown ROI or ROI less than investing the money elsewhere (ongoing maintenance and upgrade included).
The following are not reasons to upgrade:
- need to have support and maintenance
- solving a hardware issue with a software upgrade
- keeping up with the Jones’
- enamored with the next shiny object
Also new software as a service models have driven the upgrade model to the brink of extinction. These are all indicators that we should focus on return on investment(ROI). Since the ROI for an initial software installation rarely gets to the details of ongoing maintenance and upgrade, the ROI for the original investment can be lost once upgrades are factored into total costs. Since upgrades are added costs, it is important to look at the total case when considering ROI. This may include going back to the original ROI model and adjusting now that the additional costs are known. This also includes looking at future upgrade cycles to include them in the overall ROI. If the ROI case is significantly hindered, it is important to look at additional alternatives, including migration to a software as a service platform and/or shutting off software.
Planning process is not done or shortened.
Often, companies think that because it is just an upgrade, planning is not as important. Most times, when software is upgraded, it is just as important to plan as it was for the initial installation. There can be just as many or more changes from the initial install and the planning can be more complicated. Plans and organizational change need to be considered in all upgrades. A complete plan should be created and lessons learned from other projects and teams should be considered. No plan created is a plan to fail. Complete organizational change management should also be addressed in the plan. Involve the entire team that will be impacted and ensure that they are given time in the plan to assimilate the changes.
Software is not one size fits all.
When an initial installation of a piece of software is done it is rarely just installed and rolled out. There are configurations, customizations, interfaces and reports that are built that are specific to that installation. In an upgrade all of these things need to be addressed again. In some cases they all need to be redone. This rework should be addressed in the ROI and planning pieces above but they should also be looked at with the lens of being shut off as well. Phone applications, Office Suites and Software as a Service have learned that getting to a one sized fits all model makes that software easier and more valuable. Strive for those same things in looking at an upgrade project. It may get you to a place where upgrades are easier or eliminated.
No one shuts off technology.
What would you do in your business if a machine or a tool was not doing it’s job any more? Everyone knows you would replace it or get rid of it. Why do we not make the same determinations with software? We need to look at automation with a different lens. What if there is newer software that eliminates the need for the current software? What if we can now replace the automation with a manual process? What if the cost to keep the software running is more than the value that it is providing? All of these are questions we should be asking before upgrading software. I know of a medical office where the back office system was held together by one office manager. When that manager left the company the owner was in a real pinch. He has not made the decision yet to shut off his software, but that is one option he is seriously considering. It is a path that may sometimes make sense.
About the author:
Greg Stellflue has 25 years of experience in project management, application ownership and software development. With over 30 years of industry experience he has focused on advancing information technology capabilities in many different organizations.
If you are interested in a free assessment of your IT or just coffee sign up below.