It’s become popular to comment that people are resisting the kind of change that you’re proposing.  Whether you’re making a minor change, changing a software solution, or focusing on an organizational transformation that seems to be encountering resistance, it’s easier to make it about “them.”  “Those people” are resisting the change – and that’s the excuse for a lack of success.

Real Resistance

There is real resistance in every change effort, but it’s not people resisting change.  The resistance that you’re feeling is related to the sense of loss that the individuals have.  The loss may be real or simply imagined, but that loss aversion is what you’re seeing as resistance.  Knowing that it’s not the change they’re resisting but loss, you can focus your efforts on neutralizing the resistance.  (See Managing Transitions for more on resistance to loss.)

There are two strategies for reducing resistance to loss.  The first is to create a higher degree of safety.  The more that people feel safe about where the change is going and have trust that leadership will get them where they want to go, the more willing they will be to accept small losses.  Resistance is highest when safety and trust are at their lowest.  The second strategy is ensuring an accurate appraisal of the loss.


We tend to believe that safety is an absolute.  Something is either safe or not.  However, the truth is that safety is about our perception of our ability to survive.  We evaluate stressors and assess both their probability and their potential impact against our capabilities, both internally and through our network of relationships.  (See Why Zebras Don’t Get Ulcers and Emotion and Adaptation for how we manage stress and process potential threats to our safety.)  We are further influenced by environmental factors like the time of the day and familiarity, because these influence our perspective on both the risk and the resources we have available to ourselves.


Trust is a simple concept with a great deal of complexity behind it.  Trust is the degree to which we expect that our predictions about the behavior of others will match their actual behaviors.  The greater our beliefs that they have our best interests at heart or will look out for us, the greater our trust.  The problem is that trust is built through a long road of making and meeting commitments and can be destroyed by a single slip.  These slips are betrayals – they’re where our prediction of the other person’s behavior didn’t match.  (See Trust & Betrayal in the Workplace for more.)

If we want to reduce resistance, we can increase trust.  This can be done through making and meeting commitments or through something as simple as increasing the frequency and transparency of our communications.  We can also use credibility markers to strengthen the perception.  Others exhibiting their trust in us can powerfully elevate the level of trust that someone else will develop in us.  We can also find ways to communicate our competence to others through stories of prior experience, certifications, and degrees.  These all convey to others that we are likely to meet the expectations of us.

Loss Appraisal

Sometimes the problem isn’t a perception of a lack of safety or even a lack of trust.  Sometimes the problem is that the loss appears too big to be handled.  While it’s true that some changes will have far-reaching influences that may be too much for someone to adequately cope with, in most cases, the degree of loss is smaller than it appears to the person who is being asked to make the change.  Simple losses like a loss of familiarity with the approach spiral into feelings that you might find them to be incapable of the new way of working and that they’ll lose their job.  If they lose their job, they’ll be unable to find another job or pay their mortgage, so they’ll lose their house and have to live on the street or worse – move back in with their parents.

Sometimes the key to adverting loss-based resistance is to simply take a closer look at the real impact of the potential loss.  Instead of allowing the employees to connect the dots in the most psychopathic way possible, perhaps you can candidly walk through the potential losses and scope them appropriately.

There are some folks in the change management community and profession who rail against those who are willing to quote a 70% failure rate.  They believe they’re uneducated, and they don’t understand that the numbers aren’t supported by science.  This is my response: I understand enough about science and statistics to say with reasonable confidence that the number is within the ballpark of correct – given a set of constraints.

Let’s tear this down to explain what the 70% failure rate for change projects means and how, in one critical definition, a 70% failure rate is generous.

What is a Change Project?

Here’s the first issue we have.  Change projects can be anything from a change that has no employee impact – such as upgrading from one email server to the next version – to the kinds of continuous quality improvement exercises that Deming taught us to do and the kinds of change that are transformative to the organization.  To be clear, I’m confining my responses here largely to transformative change – the kind that the 70% estimate was initially intended to represent.

While the other kinds of change projects are quite valid and correct, they weren’t what the original proponents of the 70% number had in mind.

On Time, On Budget, and On Value

The starting point for our evaluation of change project success must be overall success of the project when measured as to whether the project was delivered complete, on time, and on budget.  The research by McKinsey and the University of Oxford suggests that largescale software projects are 45% over budget, 7% over time, and deliver 56% less than predicted.  (See Delivering large-scale IT projects on time, on budget, and on value.)  The publicly available data doesn’t explain which projects each apply to, but if we apply an even distribution, we get roughly 78% of projects with some sort of failure to meet all three criteria (108% total minus overlap of ~29%).

One could argue all projects are not like IT projects – and I’d easily agree.  I’d say the kinds of large-scale IT projects that were being studied had some degree of organizational transformational aspect to them.  If I had to venture a guess, I’d say that organizational transformation is harder than IT projects.  But if we use just these criteria that have a research study behind it, we’re over the 70% failure rate that is used as an estimate.

A Lack of Research

The primary argument leveled against the 70% failure rate has been that it wasn’t based on hard research.  Anyone who knows anything about statistics should know this instantly.  Statistics almost never land on round numbers.  For instance, Edgar Dale’s cone of experience has been widely misinterpreted over the years.  The idea is that some people learn one way or another.  Percentages were applied to the cone at some point, and they stuck – despite the fact that Dale himself didn’t add them, and their round numbers stand out as having limited possibility to be based on research.

In short, if the percentage ends in a zero, it’s an estimate – not a statistical proof.  (See Superforecasting for more.)

However, I can, of course, look for other studies for other kinds of projects with varying results.  The one I quoted above was literally the first result I got back when I queried for project failure rates – in short, Google thinks it’s representative of the kinds of results people are looking for.

Establishing Criteria

What’s wrong with this?  How is it that the numbers can be so bad?  The answer is in the standard that I used for success.  I said everything had to go right.  The reality of organizational change is that nothing goes right all the time; there are always issues.  If I relax the criteria to just budget – or just the projected features are present in the software – well, the numbers get better.

The truth is that we’re simply talking about the criteria that project managers use for success.  Take the Sydney Opera House.  They spent 17x the initial planned budget – but few people would consider it a failure.  The result is, then, that the criteria being used for success may – or may not – be the right criteria or at least the criteria that others are using.

Conflict of Observation

The second major issue that is raised when disagreeing with the estimated 70% failure rate is that it doesn’t match consultants’ observations.  Because it doesn’t match their success rate, it must not be right.  The problem is that the consultants have fallen into the trap of sampling bias.  That is, their clients are the ones who are committed to the change enough to pay for the consultant.  They’re forward thinking enough to realize that they need help.  These are the kinds of organizations that are most likely to succeed.

So even if the consultants were completely ineffective – as some are – they wouldn’t see a 70% failure rate.  Their clients have self-selected themselves into a premium position of caring and therefore doing better than the average.

Read the Journal Articles

The most tragically humorous aspect of the arguments that 70% of change initiatives don’t actually fail is that the authors of such arguments seem to have failed to completely read the entire journal article they’re citing to refute the 70% number.  The article “Do 70 Per Cent of All Organizational Change Initiatives Really Fail?” by Mark Hughes points to the problem of identifying what we mean by failure – and what we mean by change.

Hughes’ point isn’t that the number isn’t as high as 70% – his point is simply that the number itself is unsupported by research.  It could be that 90% of change initiatives fail when measured by project management terms and when they’re transformative.  Hughes simply doesn’t know.  Neither do I, but in the spirit of Douglas Hubbard’s work, How to Measure Anything, I can make a reasonable statement that the initial estimate of 70% is reasonable – given a tight definition of what success is.

So the next time someone tells you that 70% of change initiatives fail, you can answer that there’s research that says many large scale projects fail at a similar rate with the tight criteria of on time, on budget, and on value.  There’s no reason to believe change management projects are any different.

You walk up to someone at a party and announce that you do change management work.  They reply, “Wow, that’s amazing.  So do I.”  And you spend the next 5 minutes engaged in a conversation about change management that feels as if you’re speaking two different languages.  You’re talking about organizational transformation, and he’s speaking of how to manage the configuration changes on routers and firewalls.  Both are change management – and both are very different.  Let’s look at what change management is and why it’s so hard to reach agreement between two people about what it is or how to manage change best.

Configuration Management

Perhaps the easiest thing to explain that falls into the category of change management is sometimes called configuration management.  It’s the change control process for making configuration changes to a process.  Whether the process is an IT system or a manufacturing pipeline, the changes are documented, and then approved or rejected, implemented, and sometimes retracted.

This kind of change management is designed to maintain the status quo and ensure reliability.  To those who are entrenched in managing complex systems, this is the only kind of change management there is.

Continuous Improvement

A close cousin to configuration management is the idea of continuous improvement.  Deming promoted a Plan, Do, Check, Act (or Plan, Do, Study, Act) cycle that’s designed to be iterated continuously in an organization to leverage small improvements in productivity, efficiency, quality, and other desirable aspects and their compounding nature over time.

This has been enhanced through Lean manufacturing and the Toyota Production System to includes rapid improvement events.  These events attempt to short circuit the continuous improvement cycle to kick start it into rapid acceleration.  This process has great value, but the improvements are often incremental and evolutionary rather than revolutionary.  It’s akin to opening your own video rental store with better prices, services, and hours.  However, it leaves room for transformational changes that can rapidly overwhelm a continuous improvement approach.

Transformational Changes

Another kind of change is a transformational change that doesn’t seek to squeeze more efficiency out of the process but instead asks whether the process is fundamentally right.  While techniques like Lean are designed to ensure that everything in the process adds value to the customer, this is often overlooked or is so narrowly focused that it misses the forest for the trees.

Transformational changes are, by their nature, revolutionary.  They change the way things are done, and this can often make people uncomfortable. However, this discomfort is precisely the tool that corporate planners use to create the energy necessary to initiate and sustain the change.

One type of transformational change is organizational change, where the nature of the transformative change is changing the nature of the business.  Historically, these projects have been known by several names, of which “organizational change” is simply the latest.  What used to be reengineering has lost its scientific armor and has fallen to the regular challenges of the volatile, uncertain, complex, and ambiguous world that we all find ourselves in.

Different Strokes

The kinds of tools and techniques you use to address configuration management is radically different than the kinds of tools and techniques you use to manage an organizational change management process.  It’s not that one set of tools and techniques is better – it’s that they’re a better fit for one kind of change project or another.