Published on the 24/03/2015 | Written by Peter Dickinson
If the consequences of a failed software project were the same as for a bridge or building, there would be some significant piles of rubble, numerous casualties and a whole lot more court cases. By Peter Dickinson…
Don’t get me wrong. I’ve had a forty year love affair with the software industry and can verify first hand that it improves lives, saves resources and generates more income for businesses – it is an absolute game changer. But the software industry is also one of the most wasteful and debilitating industries on the planet.
The numbers are so large the statistics don’t seem real. The global cost of IT project failure is calculated at US$6.2 trillion per annum with an estimated 15 percent of projects being abandoned pre-launch or shortly afterwards. A survey of businesses in Europe established that up to 50 percent of purchased software is never effectively used – a good percentage of it never actually being deployed at all.
This catastrophic ongoing pattern of failure and waste seems to be accepted as part of the high risk we pay for the reward of progress. But should it be?
It isn’t that those in the software industry are necessarily negligent and by all accounts the IQ level is higher than most. So why don’t we have the same expectations of those engineering our software as we do for those engineering buildings and bridges?
I see three main drivers for the waste that occurs:
1. The technology industry celebrates platform change. While there can be real improvements associated with a platform shift, very often it is a thinly disguised commercial opportunity to turn existing customers into new customers all over again.
2. Love of shiny new things. Disruptive thinking is in every software developer’s DNA. As a result they’re always pushing the boundary and see their latest solution as the only solution and demand that everyone immediately embrace its brilliance. The question as to whether you really need to upgrade (or not) is never asked.
3. The most critical cause of all: A disconnect between developers building technology they love as opposed to building what the customer actually needs. It is an age-old information gap but the void between customer and developer is larger than most.
It means we see the software equivalent of a lot of new mouse traps in a year. We also see numerous projects fail because what the customer actually wants isn’t getting heard. Or if it is being heard, then it isn’t being interpreted accurately so the outcomes that are delivered miss the mark.
At some level software is also viewed as highly replaceable. Because it is constantly evolving and changing even a completed project is never finished – there are constant upgrades and improvements as the technology and business requirements continue to evolve.
As we’ve already discussed this can create a rip and burn mentality; out with the old and in with the new, requiring a complete rethink and often a rebuild every time your business grows and changes. This is not such an issue when your company (and comparative investment) is small or if the software sits at the periphery of your business.
It is an entirely different matter when you are discussing replacing the core-system that runs every aspect of a business. Then the decision to shift house is an expensive and disruptive undertaking and something you don’t do lightly.
And this is where the engineering and architecture of your software really comes into play. You shouldn’t have to shift house to accommodate expansion or changing business requirements. Growth is the fundamental focus of every organisation and any business management system worthy of the title, should be able to expand with you – effortlessly.
Some ERP software players are addressing this issue by bolting on some new bits which is easily done while business goes on as usual. But it is the equivalent of window dressing a leaky building – it looks and functions OK at a surface level but you don’t have to dig too deep to start finding areas of pain: processes that aren’t integrated, areas of the database that aren’t searchable, parts of the program that require a manual work-around.
The excuse is generally that renovating the building while you still occupy it is too hard and too costly. I would argue that should never be the case if the underlying platform and architecture you have in place are built to last. Change is inevitable and if your core business systems aren’t built to change and grow then your business will continue to be limited by the software it’s using.
So what lessons should you take from this? Firstly don’t be distracted by the window dressing. When you’re buying software pay as much attention to its architecture and engineering as the processes and systems it automates for you. Ask the hard questions around meeting the growth challenge and assess how easy it will be for you to execute add-ons and renovations while you continue business as usual. There is truth in the statement that a building is only as good as its foundations. The same is true of software.