If It’s Not Broken, Why Update It?

photo credit: Sean MacEntee via photopin cc

photo credit: Sean MacEntee via photopin cc

From a business perspective the saying “if it is not broken don’t fix it” is often applied to IT systems.  Finding the investment to keep up with the market can be a challenge, and it is often tempting to just avoid any efforts or costs of an upgrade.  Even on our mobile phones we all fear that notification that a new version is available and hit the upgrade button with trepidation; not knowing if the app will successfully install or worse, the whole phone dies.  When applied in the business enterprise that trepidation translates into an inertia to upgrade that can become a massive penalty down the line as the gap to the latest version opens up.  This gets worse as the enterprise gets larger and the decision making more centralised.

When Microsoft was founded along with the PC it succeeded in trumping the IT department and mainframe computing because business departments were able to buy their own machines and software, avoiding the central controls.  The nimbleness of decentralised purchasing led to rapid deployments and fast up-take.  Fast forward to ten to fifteen years later and that same purchasing has now been centralised. In one large global insurance group the bill had become over €20M for the Microsoft Enterprise agreement for licences and was approaching the biggest single biggest spend in the group, annually needing a Board decision to approve it.  As an aside it was probably big central visible bills that almost killed IBM in the 1980s, so it is no surprise that Microsoft is now suffering from the same central exposure. In other words, watch for the new wave of decentralised spend as the Cloud products take over in big business… but that’s not the topic of this blog.
Now, if we also consider the centralisation of the agreement that has been made in parallel with a centralisation of the decision making on upgrades, you can see that there is a danger of upgrades not being applied. The board will constantly find reasons to avoid upgrades that keep up with the market and divert that spend elsewhere.  As a result many larger organisations are now lagging well behind the marketplace on versions of their core software because there is an aversion to the risk and spend of the upgrade.  Taking the global insurance group as an example, they were three major versions (at least) behind on the core operating system versions, three on their browser and two on their office products. Not a big problem one would think as it all works fine.  The trouble is each time the next version comes along the upgrade costs are getting bigger and bigger.  The costs of rolling out, coordinating and re-testing the applications used by more than 200,000 users is not to be underestimated and in this case the cost was estimated at €8M.  The problem is that every year the IT team put forward the need to upgrade and every year it is deemed not worth the spend.  This inertia starts to cost in other subtle ways, such as difficulty in sharing documents, vulnerability to viruses and other external attacks and difficulty browsing websites.  What is now happening is that firms are on such an old version that the tools to allow a seamless upgrade jumping so many versions are not available and so the project cost is sky rocketing, in my example case it could exceed €20M to plan it and retest everything.  Worse still, the versions that the firms use are now so old the support costs are also sky rocketing, leaving them no choice but to act – perhaps at the worst possible time for business.
Mapping out your business usage of technology and knowing when the upgrades are imperative is an important part of your IT and business strategy. Do not wait until things are broken, plan your upgrades and balance risk with cost so your are not caught with a huge bill at an inconvenient time.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>