Module 01 · 15 min
Why Change Projects Still Fail
The success rate has barely moved in thirty years
Set the baseline: what success and failure actually mean, what the evidence says, and why the reasons everybody already knows have not fixed the problem.
Defining success — and failure
“A successful project is one which achieves its outcomes on time, within budget and to the required level of quality, realising the benefits identified in the Business Case.”
“Failure is usually defined by the host organisation in terms of projects that are late or over budget, an inability to fully realise the expected benefits, or to gain the acceptance and enthusiastic support of users and management.”
Note what both definitions have in common: benefits and acceptance sit alongside time and cost. A project delivered on time and on budget that nobody uses is a failure that shows up as a success in the project board pack.
What the evidence says
- The Standish Group's CHAOS research has reported successful project rates in the low thirties for most of the last two decades — roughly one project in three.
- Bent Flyvbjerg's work on large projects (How Big Things Get Done, 2023) found that across more than 16,000 projects, only a very small minority came in on budget, on time and with the benefits promised.
- McKinsey and the University of Oxford found large IT projects ran on average 45% over budget and 7% over time, while delivering 56% less value than predicted.
- PMI's Pulse of the Profession has consistently reported that around a third of projects fail to meet their original goals, and that a substantial share of every programme pound is lost to poor performance.
Different methodologies, different decades, same order of magnitude. Agile, DevOps, cloud and AI-assisted delivery have changed how we build; they have not changed the headline odds on organisational change.
The reasons we all already know
- A focus on the technology instead of the business benefits
- Poor specification of the system and shifting requirements
- Weak leadership and absent senior championship
- Lack of due diligence on supplier capability
- Inadequate resources allocated
- Poor project management
- Lack of genuine user involvement
Every one of these appears in every post-mortem, every lessons-learned log and every audit report. If knowing the reasons were enough, the failure rate would have collapsed years ago. It has not. So the list is not the explanation — it is a list of symptoms.
Key takeaways
- Roughly one change project in three fully succeeds, and that number has been stable for decades.
- Benefits realisation and user acceptance are part of the definition of success, not optional extras.
- The familiar list of failure causes describes symptoms, not the underlying mechanism.
Take it back to work
- Of the last five change projects in your organisation, how many delivered the benefits in the business case?
- Who in your organisation is accountable for benefits twelve months after go-live?