I'm wondering whether the phrase '70% of change efforts fail' is down to not knowing how to get from a design to an implementation – so things stall at the point of a detailed, tested concept design. The 30% that don't fail may have cracked the process of a) planning to get safely from current to designed state and b) getting there. (Whether 70% of change fails is largely unproven but that hasn't stopped people thinking that is the case).
The topic came to mind when someone sent an email asking me to run a session with project managers where we 'delve deeper into the tools of change' which (in a previous workshop) I'd suggested included: incentives, policies, symbols, feedback, communication, education and development.
He asked 'from your experience what has worked, what's not – why to both, how can you use the tools in the project world, both internally to the project team (i.e. incentives to drive performance/change in behaviours, are there any lessons we can learn from the Agile delivery?) but also to the products of the projects'.
As I was pondering this I came across Ron Ashkenas HBR article We Still Don't Know the Difference Between Change and Transformation. He defines change management as 'implementing finite initiatives, which may or may not cut across the organization. The focus is on executing a well-defined shift in the way things work.'
He defines transformation as 'another animal altogether. Unlike change management, it doesn't focus on a few discrete, well-defined shifts, but rather on a portfolio of initiatives, which are interdependent or intersecting. More importantly, the overall goal of transformation is not just to execute a defined change -— but to reinvent the organization and discover a new or revised business model based on a vision for the future'.
This seems to me to be a useful distinction and I started to form a hypothesis that project managers confuse 'change management' and 'transformation'. And if they don't get the distinction between the two their transition plans and the implementation of them are going to lead to failure.
In my experience 'transformation' requires a good knowledge and understanding of systems thinking. (If you want to learn about this I recommend the short, free FutureLearn course Systems Thinking and Complexity)
My hypothesis began to morph towards a question – how much do project and programme managers know about systems thinking? Is there a tendency to treat transformation projects as change management projects? And if so, is that why projects 'fail'?
One researcher (2012) also asking how much project and programme managers are schooled in systems and complexity found that: 'Surprisingly, project managers do not seem to use simple systems thinking tools even though these provide unique benefits in framing and solving problems that arise from multiple perspectives and relationships.'
And in 2013, the Association for Project Management set up a group 'to promote systems thinking across the wider decision-making community in the UK in order to support the improved delivery of complex projects and avoid common pitfalls.'
The next thing to hit my inbox was a run of email exchanges about introducing the Spotify model of Product Development Units. This model involves functionally integrated, highly autonomous, self-organized, self-steering, teams, measured for performance at the team level. (See Niels Pflaeging's blog). The emails were discussing to how to effectively transition to them. An HBR article on this model discussed three challenges: balancing autonomy and accountability, balancing freedom to innovate versus following proven routines, balancing alignment with control.
If an organization is hierarchical, measures individual performance, has functional silos, and traditional management then introducing the Spotify model is not the change management Ashkenas describes as a few discrete, well-defined shifts. Because it affects the whole organization, it is the transformation that he describes as reinventing the organization and discovering a new or revised business model.
In this example, a typical change management plan to transition built around levers of change will not work. What's needed is a transformation plan – one which accommodates, what Ashkenas calls, the 'unpredictable, iterative, and experimental'. It requires not a 'tools and levers' approach but a systems thinking approach.
Now I'm wondering whether project and programme managers skilled and knowledgeable in systems (and complexity) thinking have a better track record of successful change and transformation delivery – because they can distinguish between the two and plan appropriately – than those who don't. Do you know? If so, let me know.
Naomi Stanford 