Should I upgrade to the latest phone? Should I upgrade my current car to an electric one? Is it time to move to a bigger house? These changes affect just a few people. But in any organisation the decision to upgrade software is huge and affects many.
The main difficulty is the amount of change, positive and negative, that a business might incur. Change is also often difficult to quantify, so let’s step back first and look at what needs to be considered.
Starting right at the beginning, what is the reason my organisation either needs or wants to upgrade? Wanting to upgrade is good because that usually means there is a solid reason, needing to is a bit more woolly. Having a solid rationale for an upgrade is a good place to start, because to date nobody has developed the seamless, transparent organisational upgrade that everyone would like to have. Many have spoken about it, including SAP, and for sure in some cases it has got easier, but it’s never seamless.
The most positive business reason for an upgrade is that it will improve operations through greater speed and reduced cost, whilst adding organisational enhancing capabilities. Or as one of my former bosses said “Bigger, Better, Faster, Cheaper!”.
One of the hardest, and some might say impossible, rationales to manage is that inflicted by software and hardware vendors in terms of “out of support”. This next part may be construed by some as a bit controversial.
The support dilemma
Vendors like to grow, and they can only do that by selling more, and in some well documented cases, charging more. Thus comes “innovative new products” ……which will change the way that organisations work. Trouble is that to get the new products you have to upgrade. When the innovation delivers the “Bigger, Better, Faster, Cheaper!”, then there will be support for the activity, however if the benefits are not patently obvious, and the upgrade is disruptive then we are in a completely different ballpark. Meanwhile you are likely continuing to pay your annual maintenance fees to the vendor, which is often a not insubstantial amount of money.
Some organisations find themselves between a rock and a hard place. They can’t see the benefits and find themselves pushed back against a wall for lack of product support, which could entail lack of legal and security updates. Corporate responsibility says that they have to maintain both the legal and security aspects of their solutions. Some may actually take withdrawal of support as a gesture from the vendor indicating a lack of partnership with its customers.
Getting the timing right
Timing is key, not of the software upgrade, but of the organisation’s circumstances. Things like capital depreciation, economic factors, current organisational performance, product and service launches, and changes of ownership all come into play. All of these factors dictate the amount of change the organisation can swallow – and no two organisations will be the same.
This takes us to the discussion of a so called ‘technical upgrade’ versus a functional upgrade. A technical upgrade can be an agreed interruption in service alone, which is sometimes more palatable in these circumstances.
The biggest impact by far is a functional upgrade (or changing the way the organisation works), as it impacts all the business partners and customers. There is no getting away from that, and of course good planning and mitigation activities will manage that, but it is something of a bigger scale which will mean increased cost of delivery.
A good software product will, by itself, determine its rate of acceptance through organisations spreading the word of its effectiveness.. A bad software product will flounder, and lead organisations to make decisions to take other strategic directions.
I think what software vendors need to be careful around is making fundamental changes in a way that can disenfranchise the existing customer base. Yes, customers want innovation, but it has to be something that delivers guaranteed benefit in an easily digestible way. They also want to accept it at their pace, and not have it rammed down their throats. The software industry has to remember that despite all the rhetoric about “every organisation is now an IT organisation”, at the end of the day, software services is not that organisation’s primary activity (……unless of course you are a software company).
To date, I have liked SAP’s approach around extending the support period for its products, and publishing well in advance….but it has to be flexible around the reality of where in the cycle the customer base is, if it is not to disenfranchise its very large base of maintenance paying customers.
