With my newly discovered health challenge comes a wonderful low-residue diet, which is not unlike the diet my kids had when they were two years old and started easing into solid foods. Yay, mushy food!

There are no shortage of experiences, “best practices” and recommendations from the 3 doctors, dietician and countless people I’ve chatted with on various forums.

Of course all claim their way is the right way.

According to one expert, I’m supposed to lay off coffee, well caffeine to be more specific.  Other experts say if coffee never bothered your stomach before, don’t worry about it, it’s fine.

There are commonalities between all these experts such as laying off any raw veggies or fruits with skin as they are harder on the digestive track, but overall, what works for people comes down to…uh, what works for them.  Through experimentation, I’ve discovered what works for me. So far.

And so it goes with change frameworks.

Most change experts, blogger and consultants fundamentally agree on the basics, such as good communication, executive support, and ownership of the change by the people.  Many also use the macro-model of current state, transition state future state with whatever tactics their framework uses. Some cling to what they believe is the ‘best practice’ and others recognize that pulling ideas from many models is the best approach to take.

So should you build your own change method or try one out of the box? Here are 5 factors to consider that may help you decide:

Comfort and Certainty over Fit-For-Purpose

Are you choosing the framework you like best because it’s comforting and provides you with the feeling of certainty? I believe that comfort and certainty are less important to the change agent, and more important to the people being affected by the change.  A change framework should help people adjust to the change, not force them to follow a standard path through the change.

Your change framework must have the capability to manage un-certainty as it arises. Think of it this way, if the only tool you have is a hammer, every problem is going to look like a nail.

What Type of Change are you Implementing?

I mostly work on Agile Transformations, the implementation of new software delivery practices. Most think that only affects IT, but it can effect the entire organization. The size of the organization is the primary factor for how to approach this change. Do the stakeholders want to kick the tires? Do they want to change an entire department? The whole organization? A single product or project?

For other massive changes, for example re-orgs or mergers, the un-certainty is extremely high compared to business process changes as a result of implementing a new tool. In another organization I worked at, we were implementing a new insurance system that affected the entire organization of approximately 4000 people. We *knew* what the tool did and we expected chaos as people adjusted to the new tool. The uncertainty came from when it would be ready and how we would overlap 2 systems during the transition.

How Risk Averse is the Organization?

This includes considering what the natural pace of change is like in the organization. A digital or entertainment company likely has a higher tolerance for the disruption caused by change as opposed to a bank or insurance company. If your organization is conservative and risk averse, choosing a well-known framework for optics might be a good idea. Similar to my first point about comfort and certainty, helping executives feel more certain that ‘an industry standard’ framework is being used can set their minds at ease.

Maybe that sounds sneaky, but from my experience, executives and sponsors of the change typically want to see some plan and framework is in place. The tactics matter less and you have much more freedom in picking ideas from other frameworks when you get to the execution of the change.

In this case, your change framework could benefit from these tactics:

  • big visible walls over Sharepoint sites
  • iterative planning versus all-up-front planning
  • using Agile practices, such as Scrum or Kanban to execute the change

What are the Ripple Effects?

Who is directly, and in-directly, affected by the change? How many people are affected?

Why it matters: A larger anticipated ripple effect means a slower pace. Pay attention to piling on too many changes. That can lead to burn out.  Change facilitators shouldn’t be creating busy-work if this is the case because sometimes a “wait and see” approach is needed.

A larger blast radius also means a change agent network is a good idea. That will help the change team identify early adopters which will help the change spread organically.

Who will be facilitating the change?

Is this an ‘official’ program being run by the existing change management team? Are outside consultants coming in (and are they bringing in the method they tend to copy and paste from organization to organization?) Is it a combination of both? Is someone running the change from the side of their desk?

This is important for a number of reasons and I believe the personalities of the people on the change team are the most important factors. It’s a good idea to have a mix of personalities on the team. Some should be biased towards action and feedback and others biased towards planning. That (hopefully!) will create positive tension and avoid groupthink.

Building your own change framework isn’t just about the tools being used, it’s about the people who will be using the tools.

Tying it All Together

Obviously there are more points to consider when deciding whether or not to build or buy your change framework. The 5 factors I’ve mentioned here are interconnected. That interconnectedness should also be a factor in how you decide whether to build or buy your change framework.

Like what you see?

Get a free sample chapter of my upcoming book and discover more ideas for building your own change management framework.

Get it Now!

Jason Little
Author, Lean Change Management at Leanintuit
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.