“So would you consider that a failed transformation?”, was the question from a current client of mine during a conversation about a previous client I worked with. I had mentioned that a few people I talked to a couple of years later said they ‘went back to the old way for the most part’.

“Well, it’s not that simple. Did we ‘transform’ to what I would consider to be optimal? No. Did we have a whole whack of successes and face plants? Yes.” was my reply.

I’ve called BS on the 70% failure rate of change projects before and so have many others. Organizational change is complex and attaching a binary success or failure outcome makes little sense to me. Humans like certainty. Well, more accurately, our control centres brains like certainty. The desire to satisfy that need drives our behaviour when it comes time to execute change projects.  We need to feel certain people will adopt the change, so we need to measure them.  And we obviously can’t trust the change team so we need to invent some measurements to make sure there working hard. Then we need to have our backup measurement. You know, the one that somehow makes its way onto the project closeout status report proving the change worked!

Cynicism aside, that’s the way companies work. And it’s a shame.

I believe this project-focus approach to organizational change is one of the reasons many people get frustrated by change. Forcing an organizational change to be managed by a process that isn’t designed for embracing un-certainty and complexity, leads to the preservation of the status quo. While I firmly believe a deadline and a name are the two main things that kill transformational changes, I do live in the real world, most of the time, so the focus of this post is on how you can apply lean and agile practices instead of traditional project management to organizational change projects.

First, let’s see what guidance we can gleam from the Agile Manifesto:

Individuals and Interactions over Process and Tools

That simply means get people working together to solve problems. Hmm, might be a good guideline for building your own change framework instead of following a standard process!

Working Software over Comprehensive Documentation

That doesn’t mean don’t document anything, it means, in software projects, working software matters more. What matters more in change projects? ROI? Behaviour change? Meaningful change? Positive business outcomes? Decide what is more important than change documentation and focus on that instead.

Customer Collaboration over Contract Negotiation

That means work with the customer to help solve their problem instead of nit-picking over a contract. Who are your “customers” when it comes to change projects? The people affected by the change? The dude paying the bill? The end customers of the organization that may ultimately benefit by the organizational change that is happening? To me, this is primarily about working with the people affected by the change to get their input into the design of the change.

Responding to Change over Following a Plan

This seems obvious. Have a plan, yes, but plan to deviate from said plan. Generally speaking, the higher the uncertainty, the shorter the feedback loop should be.

The most important part of using the Agile Manifesto as a guide is to adapt it to your needs. The size of the organization, the type of change, the skills of the change agents and so many other factors go into the design of a change project. Agile practices are better suited to high uncertainty projects than traditional practices.

Here are some ideas from various Agile practices you can use to manage your change project.