Demystifying Implementation - De-implementation 

De-implementation  

Over the last few weeks, we’ve taken a brief journey through the field of implementation and hopefully learned a few things.

The main takeaways are that:

• you don’t have to start from scratch if you’re trying to turn plans into action because others have put together a variety of structures to plan and assess implementation that increase the chances of an intervention achieving what it set out to do.
• There are three core elements covered in those various structures, so take time to find the one that suits your situation.
• Implementing a change in complex landscapes needs a deliberate effort around setting up many feedback loops, so planning will take more time than you think.

But wait! If new interventions keep being implemented and added to existing systems, then eventually the systems will get overloaded. This is a common phenomenon.

As systems get overloaded and become more complex policies may contradict each other, technologies may be incompatible leading to repeated actions, people will get frustrated and either be slowed down or develop random work-arounds. In these situations, the expected benefits of implementing a new intervention may not be realised because they’ll be ‘lost in the noise’.

The experience of supporting implementation has highlighted that success is often dependent on stopping interventions, procedures or processes that are removed or replaced by an innovation – this is de-implementation.

De-implementation might be new to some of you, but it is (ever-so-slowly) becoming a consideration in implementation projects. Though it probably doesn’t help that one research paper identified over 40 terms for de-implementation alone…

Essentially, I’m talking about the practice of reducing, restricting, removing or replacing an existing policy/process/intervention in a planned way.

Note the ‘planned’ bit.

Many of us can relate to the example of having new software added to our work computers (in a well-designed implementation process) and assuming that we’ll just swap over from one minute to the next because it’s ‘obviously’ better. But, some of us will hold on to the old software for a while because it’s easier - we know how to use it and it does the job.

De-implementation is not the opposite of implementation.

So, why is stopping something so difficult? Well, three main reasons are:

1. Authority vs. Influence (big boss approves change, but line manager resists)
2. Resistance to change (new ways need effort)
3. Challenging beliefs (an implication that the old way is wrong)

These challenges all need to be actively considered, planned for and resourced in the same way that you would for the implementation of something new, because de-implementation isn’t simply implementation in reverse.  

Thank you for coming along with me on this quick tour of implementation. Hopefully you’ve learned something new and feel better placed to ask questions about how new ideas will be put into practice. As I wrote before, poor delivery outcomes not only waste time and money, but also reduce confidence in both the entities and the public that expected an improvement to some aspect of their lives.

If you want to chat about implementation, get in touch here.  

For more Implementation guidance, tools and resources check out the CES online repository here.

For more guidance on Implementation you can read our Guide here.  

For more information about how CES supports implementation, see here.