One of the common mistakes that I’ve seen leaders make is to position change management within the context of the execution of a project. That is, they place the change management tasks along side requirements definition, building, and deployment.

Often the people responsible for design and build are the same people who are responsible for the change management tasks. When this happens you risk overlooking the real barriers to change.

When taking this approach, change tasks are often minimized or, even worse, skipped over because they “get in the way of progress.” I had one executive once tell me, “We’ve spoken to our users during requirements definition. We can’t keep reviewing our decisions with everyone or we will never get this rolled out. Leadership has signed off on this, it’s not like we are going to change what we are doing.”

People confuse talking to end users about the details of the change with talking to them about their reaction to that change.

It’s true that you talk to users when gathering functional and technical requirements. However, gathering requirements and content is not the same as understanding how users feel about a change.

Why can’t you talk and debate while you are making the change?
An alternative way of thinking is to consider change management as a parallel process to execution. This process should have its own sponsors and a different focus.

It’s not about the requirements, deliverables and timelines associated with the change. Instead, it is focused on how to understand and break down the obstacles that will prevent people from making the change.

Change sponsors should be the people who will feel the most pain if the change doesn’t work. These are often business owners. This is different from delivery managers who feel pain if their deliverables are not produced on time and on budget.

The goal of the change process is to understand how people are responding to the change and what is preventing them from being successful within it. Let me give you an example of a company that did this quite well.

I used to work for a very large, global partnership. There were over 2000 partners in this organization.

The leadership of the organization decided to take the company public. Now, if you know much about public versus private companies, you’ll know that this was a significant change, especially for the “owners” or the partners.

The preparation for going public took almost two years. It was a rigorous process that required hitting specific milestones and specific times in order to be ready to go on the target date. There were large teams of people working through this process.

Clearly, not everyone was excited about the prospect of being a public company. The partners naturally feared a loss of control and autonomy. There were also questions among the partners and the workforce at large about who the company would now be serving and who would reap the benefits of their work.

The company did something remarkable. They spent almost a year in on-going discussions with the partners about the change and its implications. These weren’t just process updates on progress. Rather, they were intense discussions and debates about the implications of this change.

Now, clearly, the company had no intention of changing its decision and remaining private.

However, through these discussions, the leadership of the company learned what was going to keep the partners from successfully moving toward a public company structure.

As a result, they were able to make adjustments to their strategy or add additional pieces to respond to the concerns. In the end, while there were some hold-outs, most partners were on board with the process.

This is a great example of executing the change process in parallel with the execution process. One partner might be in an execution discussion providing requirements or content knowledge for the business. Then, the next day, that same partner might have been expressing concerns about why this wasn’t going to work overall.

The discussions didn’t slow things down. In fact, I would argue that the discussions sped up the amount of time it took to get to the end state and benefit of the change.

The point is that talking with people doesn’t mean you have to slow down execution or change your decision. By talking to people you will find out what is going to prevent them (and you) from succeeding overall once the change is in place.

Let’s face it; people are going to have to grapple with the change either before or after it’s made. Wouldn’t you rather get the issues out in the open proactively instead of having to fight fires once the solution is implemented?