Change is often overwhelming for the manager and those stakeholders who are impacted.  However, a change is rarely the sole source of these overwhelming feelings.  More frequently, it’s the large set of changes that are necessary to reach the desired goal and the feeling that they all must be handled now.  The trick is to find the keystone changes that provides a firm anchor for the changes necessary to reach the objective and accomplish those changes before pursuing the next set of changes that will move us forward to the desired state.

Bad Habits Travel in Packs

The unfortunate news from addiction recovery is that bad habits like smoking, drinking, and poor eating tend to travel in packs.  That is, one of these habits tends to drive the others.  These influences flow in every direction, and they form a network of behaviors that tend to keep people trapped.  Organizations have similar sets of interlocking activities, processes, and sub-cultures that tend to hold the status quo in place.

When identifying keystone changes, it’s essential to identify which of the changes that need to be made can be made relatively independently of other changes.  It’s only by identifying which changes must be accomplished together and which changes may be accomplished relatively independently can we hope to untangle the ball of change into packages that can be tackled without becoming overwhelmed.  Finding a small set of changes that can immediately return value is key to getting the change process rolling.

Creating Slack

To create change requires effort, and expending the effort requires available capacity.  One of the keys to locating the keystone changes that need to happen first is to evaluate whether making the changes will allow you to save resources immediately and therefore reinvest those resources or whether the change is necessary but will only return on the investment after a long time.

Keystone changes make an immediate – or at least short-term – positive impact.  They free resources toward other larger aspects of the roadmap towards the desired state.  This positive impact helps to provide the energy necessary to sustain and accelerate the change.  If you don’t find changes that provide immediate impact, you may find that your change project runs out of steam before it reaches the desired goal.

Breaking Big Changes

While habits may travel in packs, and therefore you may need to accomplish several changes simultaneously, it’s equally important to decompose big steps into smaller steps.  For instance, you may need to improve the employee onboarding and offboarding processes to make the personnel management less burdensome.  While these processes are inextricably linked, they don’t have to be addressed at the same time.  If you see the word “and,” you should ask the question whether both need to be done.

Similarly, onboarding is a big process involving human resources, payroll, information technology, and facilities.  The keystone change may be changing the human resources aspects of the onboarding process – perhaps getting to a centralized human resource information system or at least getting to a unique employee ID number.  The next step might be to automate their provisioning in payroll, information technology, and facilities.  However, it can be that just managing the human resources aspects provides enough slack to keep things moving forward without anyone feeling overwhelmed.

Easier Said Than Done

In truth, it’s easier to say that you’ll identify the relationships between tasks and break them down into small, achievable changes than it is to do them.  However, if you can find those tasks which can be successfully completed without getting tangled by other changes that haven’t been made yet and provide immediate value, you’re on the way to laying down the keystone changes and, ultimately, to change success.

Any musician knows it’s the rhythm provided by the bass that holds the music together.  Whether it’s the electric bass providing a resonating reminder of the tempo the musicians share or, more commonly, the big bass drum pounding out the sounds that synchronize, music is held together by a tempo communicated through the bass.  In your change projects, you’ll need to find your own tempo for the project and your own tempo for communicating the change.

The Tempo of Change

Sounds don’t have one tempo.  Some are fast and some are slow, but all have their speed, which provides energy.  In change projects, the tempo is shaped by the size of the project – with larger projects generally requiring a slower pace and smaller ones being able to move more quickly.  The tempo is also shaped by the urgency of the change.  The more urgent the change is perceived to be, the more quickly the change must progress.

This master tempo of change drives the tempo of communication, just like the drum drives the speed at which the guitarist and pianist play.

The Tempo of Communication

The bass drum doesn’t play on every note or every beat.  It plays rhythmically to remind everyone the time.  Constant bass drum may work for a while – particularly when you want to drive energy into a song – but it quickly becomes tiring.  When planning the tempo of communications for a change, it’s important to first assess the intended tempo of the change and match the tempo of the communications you send to that tempo.  By matching the tempo of communications to the tempo of the change, you’ll begin to shape how others feel about the change – and hopefully get them swept up in the change itself.

Sometimes drummers and bassists intentionally lead or lag the existing tempo.  That is, they recognize the need for the music to speed up.  Perhaps it doesn’t feel like it’s got enough energy, so they push the tempo a bit to get to something that feels better.  Similarly, they can lag a bit to slow things down when it feels like everyone needs a break or the music is going too fast for everyone to stay together.

We can use our change communications in a similar way.  If we want to amp up the energy and the tempo of the change, we increase the frequency of the communications we send.  If we need to slow things down a bit to let everyone catch their breath, we intentionally pause or slow the bass line to give everyone a breather.

The Communication Kick Drum

A common challenge when considering your communications for a change project is how the work will get done.  With so many things going on in the change, how will you write all the content that’s needed?  The answer is to create some anchor content ahead of time and fill in with things as they’re happening.  Musicians know what the bass line will be, what the tempo will be, and what the key notes will be.  You can do the same.

While not all content can be pre-created, a lot of content can.  The kinds of content that get people excited about what they’ll be able to do, why we need to make the change, the vision of the future, etc., are all pieces that can be built and scheduled to go out on a regular basis.

While there is undoubtedly content that will need to be customized to the time and crafted right before it’s sent, you can get a head start by preparing content ahead of time and doling it out at an appropriate time.

Practice What You Preach

For us, we have built communications guides that are short and can be sent out to everyone regardless of where we are in the project (  For our Microsoft 365 projects, we have engagement videos that are designed to show them what’s possible with the platform (  We therefore have a library of resources we can pull from to create weekly, semi-weekly, or monthly communications.  This dramatically reduces the amount of content we need to create and allows us to keep the beat going even when we’re faced with a seemingly overwhelming amount of work.

More broadly, while there’s a blog post a week, we don’t write them right before they post.  We put them in a queue, and we pull them out one at a time so that you get a consistent rhythm to this blog – just like you would want in a change project.

Wedding days are a magical moment that girls and boys dream of from the time they’re little.  They get to be prince and princess living happily ever after.  However, this is generally where the dream – or fantasy ends.  They focus on the event.  They believe the transaction that is encompassed in the wedding ceremony is the thing they should look forward to.  Without taking away from the magic that can be the wedding day, there is more – the marriage.

In the context of a deployment of a new system, we often look forward to the launch day with the same dreamy expectations that it will be the culmination of the project.  The truth is, however, that the success of the project is not about the launch day, it’s about the adoption and engagement of the users after the launch is completed.

The Big Event

There is so much focus and preparation on the big event that it’s hard to see beyond it.  There are invitations to be sent and decorations and dresses to buy.  There are so many details to attend to – and those details can block the view to the other side.

As spectacular as the moment is – whether a wedding or a launch – it pales in comparison to the long-term commitment to the project or the marriage.  So while it’s natural to focus on the details of the launch and ensuring that everything is just perfect – or as everyone eventually finds out, as perfect as it’s going to be – it’s a shiny distraction from the long-term cost and commitment that the project will take.

Having “grown up” in software development, one thing was drilled into my head.  The cost of maintenance – the long-term support of the software you develop – will far exceed any costs you spend developing it.  It’s easy to say that this is no longer the case given the pace of change today – but good systems that deliver the most value to the organizations they’re used by always cost more in the long run than the initial burst of cost associated with the development.

The Merger Marriage

Some marriages look like partnerships – but only partnerships.  The two individuals make a contract with each other.  They agree to merge their finances, houses, and lives.  But it’s tit-for-tat.  I agree to do this but only if you do that.  While this is a basic collaboration strategy, it falls well short of the richness that can be found in a marriage.  (See The Evolution of Cooperation for more about tit-for-tat and other collaboration strategies.)  However, this strategy is a minimal investment strategy.  That is, each party invests what they minimally agreed to – and as a result, they get back the minimum that the other party agreed to.

There’s a different way of working on a marriage, where both parties invest just a little bit extra into the marriage than what they think they’ve committed to or that they’re getting out of it.  The result can be a level of trust, intimacy, reward that looks completely different than a merger marriage.

In change efforts, if we don’t find ways to invest just a little more effort in helping everyone use the results of the change, we may find that we achieve the goal of the change but fall well short of what is actually possible.  The organization may get return on investment if 20% of the impacted groups use the solution.  Perhaps that’s what the evaluation criteria for success was.  If you get 20% of users to contribute to a knowledge management solution or to update their profiles, the organization will, presumably, get the value that it wants from the implementation.  Shooting for the goal and intentionally stopping robs the organization from the impact of reaching 40% of even 80%.  While there are no guarantees that the greater adoption will result in greater results for the organization, it’s likely that the results will increase.

The difference between the merger or the success and the fulfilling marriage and overwhelming success lies in the amount of effort that you’re willing to put forth, not just in the development and launch (wedding) but in the willingness to make sustained commitments after the big day.

It comes up as a casual comment.  “We’re facing some change resistance.”  Your ears perk up and you wonder what’s leading to the perception of resistance.  As you and the commenter begin to explore, you realize that it’s not some magical force of resistance, it’s simply that the project isn’t moving as fast as hoped because of mass or inertia.


Objects at rest tend to stay at rest.  In fact, organizations at rest also tend to want to stay at rest.  There’s an initial burst of energy that is required to break through the inertia and get things moving.  However, what is often ignored is that this inertia doesn’t occur once for the organization, it occurs in the organization, in the department, and in the individual.

Sequentially breaking the inertia for each department and individual may be no big deal.  However, if the initial burst of energy wasn’t large enough, it can seem like each new department and individual is a struggle.  Like launching something into orbit, with enough energy, things get going and seem to continue to circle effortlessly.  If we start with enough energy to fully break the inertia, the additional departments and individuals seem to just fall in line.  If there’s not enough energy in the initial launch, there may be no way to recover.


As a fundamental matter of physics, the amount of force in an object is the mass of the object multiplied by the square of the velocity.  Therefore, as we accumulate more mass, we need more force to keep moving forward at the same speed.  That means that we can’t kick off our change project and expect that it will coast forward on its own.  We must make continual investments in pushing it forward.

What we may be seeing as resistance may not be true resistance but simply the reduction in speed due to the increasing size of the change – or it may be friction.


In a complete vacuum, you can start an object in motion, and it will continue forever.  However, our organization aren’t vacuums.  Everyone has their own perspectives and beliefs.  Our change efforts naturally bump into these perspectives and beliefs and are slowed by the process.  That is not to say that friction is all bad.  The people’s perspectives and beliefs that the change collides with may be changed.  Like billiard balls on a pool table, they may begin their own motion and start to influence others towards the change.


Ultimately our change efforts should be like flywheels. They store energy in rotational energy and release it when they need to produce results.  To accomplish big changes, we need only to continue to add more energy to the flywheel than is taken out.  As the size of the change increases in scope, we need to increase the number of people who are adding energy to the flywheel, so that more can use that energy to accomplish their transformations as a part of the change effort.

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.