People are excuse-making machines.

In healthcare, I find that people use "patient safety" as both a reason to change and a reason to avoid change.

People will challenge the data, challenge the analysis, challenge anything they can to avoid having to change how they do things.

We know from neuroscience that after a while, how we do things becomes hardwired in the brain.

So we first have to unlearn and unwire the old connections to be able to learn new ones and grow new neural pathways.

Every team has three players: dreamers, realists and critics. 

Dreamers can see the future. Realists can implement it. Critics can tell you everything that's wrong with it.

Some critics want to avoid a failure of a change. Others want to prevent it.

The latter are the corporate immune system; they try to kill anything new and improved.

To succeed at Six Sigma, learn how to wrangle the critics.

And most people fail to anticipate the costs of not improving their work.

It should also be noted that change "resistance" is not always what it appears to be.  In one instance, a manager proposed certain procedural changes.  The implementation team recognized that a similar plan had been unsuccessfully attempted before and suggested certain changes to address problems that had been encountered before.  The manager labeled the team members suggesting changes as change resisters and subsequently as change saboteurs when the procedural changes did not produce the desired result.

In another instance, a management team adopted a productivity software package w/o consulting any users until after procurement was complete.  Despite being told that the software was critically, perhaps even fatally flawed, when applied to the agency's existing business model and procedures, management insisted on a system-wide rollout.  One of the flaws of the system was that it benefited one department by making other departments do all the data entry for the system.  The departments doing the data entry not only got no immediate benefit from the data entry, they also still had to maintain existing paralell systems for their managers and received only limited and poorly defined benefit from the new system several years in the future.  Yet management labeled the failure of the software package the result of "change resistance" on the part of the other departments.

Now don't get me wrong, I am all too familiar with change resistance.  I have had to manage change resistant employees; and, I have had employees sabotage changes.  As managers, however, we cannot hide behind the excuse of change resistance when we shoot ourselves in the foot.