This blog was written by one of our Business Development Managers.
Weekly I help organisations tackle this question. It’s a big question and one with many considerations.
The typical scenario is it is time to upgrade a critical business system. The ‘cost’ of the upgrade is not to be sneezed at so it prompts the consideration and exploration of options. This is especially the case where there is a belief the system could be doing more to support the business.
I enjoy these advisory discussions as they are healthy and are all about the best business outcome. It’s no secret that there are pros and cons to both options. So how do I work through this challenging decision making process with organisations?
First, there is a fundamental question: Are your business and IT requirements being met? Both now and in 3-5 years’ time?
If the answer is no, don’t just jump to a ‘we need to change’ conclusion. Consider why it’s not a good solution currently.
I find there are three scenarios here:
- A common answer is that there has been a high level of worker turnover and there is no longer enough internal knowledge to advise. The system is judged on its performance and use now, not on its ‘ideal world’ actual capability.
- It was designed 10 years ago and the business is now different; the system hasn’t been reviewed, adapted, or optimised during that time to address your business processes. Manual processes have crept in and now Excel is a common feature. There is no integration, deployment options, mobile etc.
- Fundamentally it’s no longer a good fit for the business requirement or IT strategy. It’s been ‘outgrown’ or lacks extended capabilities.
Let’s deal with scenario 1 and 2 (which commonly go hand in hand). The question then is can we get what we need to meet our requirements and IT strategy from the existing system? Is it just that we aren’t taking full advantage of it? Or is it just not a good fit anymore? If there isn’t adequate understanding and knowledge within the organisation to answer this, research it, and talk with your partner about your system’s core competencies, additional modules, and customer use cases. Does the vendor have a vision and a roadmap for the future? Are they adapting and adopting new trends and technologies from the general business landscape (e.g. cloud, mobile, in-context BI, process automation, security)?
Unless it’s a clear case of scenario 3 above, the answer is often the existing system could be valid with enhancement.
From here it’s typical (either from a want to validate the current system so that it ‘ticks the boxes’, or due to a purchasing governance requirement) to still evaluate a couple of other solutions. Done the right way, and for the right reasons, this is a healthy process to go through. I do want to emphasise ‘the right way and the right reasons’ as it will take up a lot of your time, and others.
In this evaluation, an important point to consider when comparing ‘costs’ between an ‘upgrade’ verses ‘new’ is this – whilst the external cost to upgrade verses implementing in a new system may look similar on paper, ensure you factor in the other ‘costs’. Typically, new systems have a considerably larger internal cost. It takes so much more of your team’s time. Typically, the ‘A’ Team are on the project, but consider then that they are then not working on their ‘day job’ of producing business outcomes.
This extra time is spent on:
- Data preparation for migration.
- Design workshops.
- Large training periods.
- Longer testing periods as you are also trying to get familiar with the new system. (Testing is critical in both new implementations and upgrades, but will take longer with a new system.)
The above considerations can increase the overall risk. From experience, in terms of a quote or proposal provided at the time of decision-making, the cost provided for an upgrade (assuming it’s credible) has less risk to ‘blow out’ than a new implementation. There are more ‘unknowns’ which drive up external costs and time commitment at the proposal stage of a new implementation.
Another important consideration for risk is change management and adoption. Change, even for the right reasons, and for good business reasons, can be difficult. Many a project has failed, and the dollars spent gone to waste due to no change management or user adoption strategy.
Once these are considered, typically the decision is made to upgrade and use the existing system. Please don’t ‘just upgrade’ though! It is so important to plan to make improvements as part of your upgrade, and not just take what you have, and implement ‘like for like’.
If it is time to change (scenario 3), and you’ve considered the above, then here is some advice (and perhaps a topic for another blog). Hand on heart, when asked for the biggest benefit they seek from a change, at least 90% say ‘we need better reporting’. So please! Ensure you solve this by making it a focus from the start, not the end. And my second piece of advice is to address the biggest risk of new projects, which I touched on before (and so many software providers ignore): user adoption and ongoing performance support.
