3 Reasons Why You Should Build Your Own Change Method

The change management world is in love with the 70% failure stat. Many consulting organizations use this to strike fear into people looking to transform their organization by telling them that 70% of transformation initiatives fail…unless you use their method.

Ultimately when organizations use those methods, and their change still fails, they’ll tell you it’s because you used the method incorrectly. Makes sense.

The study I’ve mentioned in my writings before cite 2 main reasons for why change fails:

Lack of a structured change process

Unpredictable nature of people

Yet the greater change community still thinks that following a process, or static change method is the way to go. As proof, the ACMP has developed The Standard. Catchy name. How The Standard will manage the variability in every change initiative (namely People) is beyond me.

This Psychology Today article cites a few other reasons for why change fails, according to recent studies. The author doesn’t agree with any of them…neither do I, for that matter:

Assuming that change can be managed

People are objective and leave their biases at the door

Change can be mapped out in steps

Change ‘starts’ from a neutral point

Change itself is a worthy outcome (IE: look how Agile we are!!)

So we have plenty of reasons for why we think change fails, but can static methods or standards solve that problem?

By my last count, there are over 30 million businesses in the U.S alone, likely 10 times more across the entire world. It would be difficult to know how many organizations are trying to transform but I would take a WAG (wild-ass-guess) that it’s more than a hundred thousand at least.

There are 5 popular, or mainstream, change methods out there, and countless others so it’s a little silly to believe there is one method to rule them all. Good change practitioners take relevant components from many processes/methods/frameworks and use the parts that fit their context. I’d argue those that pick one process/method/framework and apply are the one clamouring about how 70% of changes fail. For the purposes of this post, I’ll refer to these processes/methods/frameworks simply as methods. Dictionary police, feel free to exert your smartness in the comments below. 🙂

The 5 most popular change methods are based on the number of times they show up in Google searches and the number of times I read Linked In, Forbes and Inc.com articles all citing the same ones over and over again.

Covey’s 7 Habits (1989): This is more about behaviour and habits, but is applicable to managing change.

Lewin’s UnFreeze/Re-Freeze (1960’s)

Rockefeller Habits (1990’s) (not really a ‘change method’ but it helps organizations manage living in a fast-paced industry)

McKinsey 7S (1970’s): Culture is at the core and is influenced by soft and hard factors: Staff, Style, Structure, Systems, Skills, Strategy. A change in one area affects all other areas.

CAP (1980’s): GE’s Change Acceleration Process

FLEX: Flawless Execution

Deming’s PDCA Cycle (1950’s): Formerly known as the Shewart cycle, Deming simply popularized it and referred to it as PDSA (Plan, Do, Study, Act). This cycle was influenced by Francis Bacon’s “hypothesis -> experiment -> evaluation” approach from the 1600’s and countless methods have been influenced by PDCA since the 40’s.

(Updated: May 26) BJ Fogg Model: This is one of my favourites because it simplifies behaviour change into 2 axis’: Motivation and Ability. Sometimes the change is simply too hard for people so you, the change agent, need to make it easier by helping. For other changes, Ability may be high, but Motivation is low so you need to inspire the person. I once worked in an organization where requirements were created via email. The big consulting firm that was hired felt it appropriate to start with BDD…which is a really hard practice to do. All the motivation in the world won’t help when Ability is low. We had to revert back to something more simple after they left.

I would imagine there are many more that are less known and there are good ideas in each of them. Many of these methods are similar in their approach, which is plan -> implement – > sustain. That’s a sweeping generalization because a couple of them recognize the complexity of change (McKinsey 7S is one of them) and that change doesn’t happen in a linear way. Many say that transformational change is never really done.

So given there are easily hundreds of thousands of organizations wanting to tranform and, by comparison, a minuscule number of methods, how can we expect that these off-the-shelf methods will work 100% of the time? Going further, given Kotter and ADKAR® are the 2 most common methods, how can they possibly work in every unique organization?

The short answer is, they can’t, but what they do provide is the illusion of certainty by giving change managers and executives hope that everything will be ok. Each of the methods I listed above do the same. After all, how are you supposed to sell books and consulting services unless you can ensure some type of success? Consulting firms that spout the number of certified people as a way to say their method is tried and true is backwards thinking. If it’s so popular and you claim change still fails 70% of the time, what gives?

The majority of methods assume all the people in the organization are moving through the change at the same rate and intensity.

Confused yet?

The point here is that that the organizations that are successful with change own their own change and build their own method to suit their organization. These are 3 reasons why it’s a good idea to build your own.

No Meaning, No Real Change

I remember when I started playing guitar 25 some-odd years ago. I was playing lefty because it felt more natural. For those “in the know” it’s really hard to find lefty guitars by comparison. So I used a right-handed guitar and reversed the strings. That was a pain so I decided to simply start playing a right-handed guitar. The annoyance of playing a guitar upside down was enough motivation to make this change. No amount of my buddies calling me…uh, not nice names…was going to get me to make that change until my brain decided that enough was enough.

This is true of transformation efforts. No one cares about your models and methods. No one cares about the urgency of the change. No one cares about changing their organization’s culture. They only care about what the change means to them. If you can’t help people attach meaning to a change, nothing will change, and no method will help you do that. I had ADKAR® used on me once. My manager asked me how I would rate each of the 5 levers. When I rated Reinforcement a zero he said “but you’re working on implementing the change! You should be a 5!” To which I replied “I see little-to-no evidence that management is taking this change seriously, prove me wrong“. Each person affected by the change will progress through the change differently. Your method needs to be equipped with feedback-driven practices so you can deal with that response, using an off-the-shelf method puts the focus on executing the method, not building meaning.

You Cannot Plan Change to a Finite Certainty

Most of the methods I listed are linear and plan-driven. I don’t believe that was the intent of these methods. I believe they were intended to help people understand the dynamics of change but have been implemented in systems that think of changes as being equal to regular projects. That is, there are pre-implementing, implementation and post-implementation phases. You cannot predict what will happen when change is introduced and you cannot set a budget and a schedule for change. The world of knowledge work has been beaten into the belief that being reactionary is bad. It’s often called fire-fighting. I believe being reactionary means you’ve learned how to deal with external markets, and external factors you cannot control.

Big planning up front serves only one purpose in change management: The desire for the executives and the change team to feel certain about the plan and where the organization is headed. The people who then have the change inflicted on them need as much time, or more, to truly understand this change. And no, your Sharepoint site isn’t helping. Here’s a tip, if your intranet site is getting 1000 hits a month (yay! it works!) and 100% of those hits are from the change team (whoops), it’s not helping.

One of Kotter’s 8-Steps is Quick Wins. It doesn’t happen as a step in a process and then you’re done with quick wins, it happens constantly. There is always a tradeoff between the effort of the change versus the payoff.

Tactically speaking, there are plenty of good practices from many different communities you can use to build a feedback-drive approach. You can use Lean Coffee, Agile Retrospectives, Surveys, water-cooler conversations, team lunches, big visible walls, interviews, observations and more to generate Insights about the change is being received. Remember, your change starts when the rumour mill heats up, not when the start-date on your change program gantt chart says it does.

Keeps You On Your Toes

As fun as hitting stuff with a hammer is, sometimes you need a different tool. Using an off-the-shelf method will be fun at first, until the gimmick wears off. I am a strong advocate of big visible walls and lighter-weight planning tools, such as change canvases but let’s face it, they are designed to provoke conversations only. They are a new and shiny thing that gets people interested in a conversation and nothing more. Believe me, the novelty will wear off.

The conversations you have in front of the big visible walls or canvases are what matter, not the artefact themselves.

Building, and evolving, your own approach to change puts you, the change agent, in a servant-leader mindset. If you’re adjusting to the system, without being an enabler of dysfunction, you’re doing the job well because you’re learning how to dance with the system.

I’ll clarify that last point. Being an enabler of dysfunction is ignoring your gut, and reenforcing the status quo by not reflecting those dysfunctions back onto the people in the organization you’re trying to change. For me, that’s where the art of change comes in.

I began my career as a web developer when Cold Fusion roamed the earth. Over the following years, I moved into management, Agile Coaching and consulting. The bumps and bruises I collected along the way helped me realize that helping organizations adopt Agile practices was less about the practices, and all about change.
In 2008 I attended an experiential learning conference (AYE) about how people experience change and since then, I’ve been writing, and speaking, all over the world about helping organizations discover more effective practices for managing organizational change.