Searching google for “70% failure rate” yields over 3.3 million results. There are countless studies, discussions and blog posts that focus on this 70% failure rate, why it occurs and who’s to blame.
Some of those failure rates apply to change management and some apply to project outcomes so we’re not exactly talking about an apples to apples comparison between these studies. Heck, even I’ve quoted that rate based on a handful of the studies I’ve read.
But is it a myth? Perhaps a better question is: Should we be measuring this “success and failure” rate at all?
Most of the studies I’ve read about transformation change and project outcome failure cite similar reasons. For transformation change it’s phenomena such as:
- change resistance
- leaders didn’t buy-in
- no real urgency
- people are un-predictable
- unable to change corporate culture
For project failures, the phenomena include:
- gaps in requirements or flawed requirements and other ‘requirements related’ issues
- budget overruns
- late projects
- mis-alignment between IT and business
Change management professionals, experts and consulting firms all suggest fixing this problem in similar ways:
- alignment and clear communication
- buying their tool or method (or selling the illusion of certainty)
- more structure, more process
- link behaviour to goals
- develop change capability
Keep in mind these statements are typically from the perspective of the change agent.
The list of fixes is quite long but in all cases they follow linear, plan-driven thinking. Change is not linear and it isn’t governed by planning alone.
Back to the myth.
I started poking around to find more sources that identify where this number came from. In addition to the sources I posted here (by the way, Kotter’s statement about 70% failure was from his Sense of Urgency paper in 2008, not 1995 as I had quoted previously), I found some other ones:
- Hammer and Champy – 1993
- Beer and Nohria – 2000
- Senturia – 2008
The conclusion this researcher came to is that these studies downplay the qualitative evaluation of organizational change. I’d agree with that. Today’s organizations are too complex to attach a binary success or failure label on a complex project or organizational change initiative.
Stating an organizational change initiative was a definitive success or failure doesn’t make much sense to me because I’d consider increasing employee happiness as a success even if a project they were working on was a complete disaster (as measured by being over budget and schedule and not hitting all the scope!).
Is the 70% failure rate the rainbow coloured unicorn of the business world?
The more I read about it, the more I think it is. I think emphasis on this number distracts people from change that matters. I think this number is a corner stone of how traditional change management vendors and consultants sell their clients a feeling of certainty instead of selling them a framework for how to adapt to changing business and organizational conditions.
If your desire to change how your organization manages work and people is high, you need to develop your own framework for approaching change. Obviously I am biased towards Lean Change Management because it can help you do that.
Lean Change doesn’t prescribe a linear formula or process, it encourages you to develop your own method by keeping these 2 statements in mind:
- you cannot predict the outcome of change.
- you can reduce the threat response (AKA ‘change resistance’) by involving people ultimately affected by the change in the design of the change itself.
It’s not for everyone. If you’d rather feel certain about a nice, tidy plan from Big Change Vendor A, go for it. I might work, it might not work. If it doesn’t work out, Big Change Vendor A is likely going to pin your tail on the rainbow coloured unicorn stat and tell you that you didn’t follow their recipe closely enough.
The choice is yours.