Why 70% of enterprise software implementation projects fail and what you can do to prevent it.
Many of our blogs and articles focus on Project Management and Process Improvement with a view to reduce costs and boost productivity, and yet one of the biggest costs for companies in the past 3 years (excluding the impact of Covid 19) is the cost of IT/Software blowouts.
For the last 25 years, the average success rate for enterprise applications that launch on time, on budget and work as expected, regardless of industry, project scale, budget size, and whether bought or built, is a low, persistent 29 percent (Standish Chaos Reports). Can you imagine if buildings, vehicles, or electronic devices had that same low success rate?
We explain this low success rate by saying that software is inherently complicated; that it's impossible to know what you need up front; and to get it right you must experiment, keep things open, see what works; and, in general, welcome the idea of fail fast, fail often. And if you really want to nail it, you've got to get yourself a rock star business analyst, UI designer, enterprise architect and developer. Right? But how often do you have one of those? Let alone a whole team of them?
So, even though delivering great software is hard, why can't we succeed fast succeed often? The accumulation of technical debt from wasted time and salaries from ongoing rework, excessive customisation costs, lost capex from scrapping projects, and when they do go live, lost time and productivity, and often increased workload is astronomical. All this erodes the profitability and sustainability of your business.
The good news is that we know why it's happening. And it's not your vendor’s fault, nor your development team’s, nor your customer’s. And it’s not your fault, or your staff’s fault. The root cause of the low success rate is that software engineering is the only one of the five major engineering disciplines that does not have a universally accepted method and blueprint for its products. Would you commission a new skyscraper, or chemical plant, or engine, or electronic device without a precise visual blueprint? Never! Yet businesses continue to commission multi-million-dollar enterprise applications, critical to their operations, without one.
In the absence of a blueprint, we have to rely on ambiguous and incomplete written requirements. This is what we call the requirements problem, otherwise known as, ‘That’s not what I asked for.’
The problem starts with the training in requirements and UI design because it typically involves learning a bunch of tools, techniques, tricks, and tips. But there’s no unifying methodology to connect everything together, without which there’s too much variability. People can choose any technique they want and apply it however they see fit. Getting requirements is essentially an open question of ‘what do you want?’ and writing it down, while expecting people to fully and accurately say what they want. It turns requirements into a long list of almost random features and functions.
Developed in Australia, CoreX is to software engineering what architecture is to civil engineering. It solves the requirements problem by connecting requirements gathering, UI design, and software development through a new central step of visual requirements modelling. The brainchild of Craig Errey and almost 20 years in the making, it’s purpose is to elevate software engineering to the same status as civil, mechanical, chemical and electrical engineering and give it the missing process and design blueprint, whether you buy or build your solution. CoreX boosts and standardises the capabilities of the entire IT team, so everyone can be a rock star.
Why is CoreX effective?
CoreX is based on a foundation of organisational psychology. Why? Because it’s not about just capturing ‘software’ requirements. Instead, it’s about starting with the fundamental purpose of enterprise applications – helping people get their work done quickly and easily. To do that, you need to properly analyse and understand the work, identify what drives high performance, and know how to get the best out of people. Therefore, what we’re actually doing is handling ‘work’ requirements.
When requirements are based directly on work, only those that directly support people’s work are treated as in scope. Anything that doesn’t, is out of scope; simple. On the other hand, when requirements are managed in the traditional way, they end up being on a long ‘laundry list’ of features and functions, all of which seem equally important.
Benefits of CoreX for your business and your team:
In a nutshell, CoreX creates a simple, visual, and shared understanding between business and technology.
With your completed CoreX design blueprint in hand, you can go to market and evaluate both buy and build solutions – it’s your choice. This is how it works when you’ve got the same kind of visual blueprint as the other four main engineering disciplines.
For a more detailed explanation of how CoreX works, and how it can transform your next enterprise software implementation project, download the .pdf 'CoreX Explained'
About Craig Errey
Craig has been the primary user experience architect behind the business-critical services and transactions crucial to many of Australia’s most popular websites including Commonwealth Bank, Virgin Blue, Qantas, ASIC, and the NSW Government. He works on cutting-edge technologies such as touch, medical and special-purpose applications. Craig is a registered Psychologist and holds a Masters in Applied Psychology from UNSW. As a psychologist, he understands the way people think and creates user interfaces and experiences that are simple, user-friendly, engaging and relevant. His expert insight into technology and how it is used has been called on by media outlets including the Sydney Morning Herald, The Australian, 2UE and ABC Radio. As one of our Grey Haired Gurus, Craig has worked with Performance Drivers on complex IT projects.
To find out more about how CoreX can make your next software implementation project a success, email or call Performance Drivers and Richard or Craig will promptly respond.
