Solutions only work when adopted

Adoption can only happen with research and iteration

Your team just implemented a new task management system. It is aesthetic, it is polished, it is automated. The system launches, it gets taught to you and your teammates, and you hit the ground running. Two weeks later, once the newness wears off, you decide to write a task down on your notepad, rather than in the system. It's faster, it feels more natural. The next day, you write three. The next week, you have dozens of tasks and notes in your notepad and that fancy new system is being used less and less. It's not just you; most of your teammates are doing the same thing. All of that energy and money invested in the new productivity promise is thrown out the window.

We have all been there. You or your team implements a new tool or system. It is supposed to revolutionize your work and give you more time back. After weeks and months of using it, you and your team go back to your old ways. This is the fallacy of change management.

Why does this happen, more often than not? Well, humans are resistant to change. While we can change and do, when we mix the challenge of change with the often stressful day-to-day of work, we tend to lean into what feels right, rather than what is. It is both situation and comfort that lead to successful adoption of a new tool or system.

How can we foster more efficient change management?

Below, I will go over the tips I recommend based on my experience working for and working with companies adopting new systems.

Research

As a Digital Operations Consultant, research is the cornerstone of all my work. The longest phase of my work and the phase that is returned to most often is research. When rolling out a new tool, methodology, or full system, you need to approach it with a research mindset.

What is the problem? How does this system propose to solve that problem? Who are the users of the system? Why should they adopt this new system?

I ask these questions, first, in a black box — not asking others, just making assumptions. This allows me to pressure test the need in isolation. If it passes the initial research, I involve others.

Depending on the user base, the team I am working with, I interview about 5–10% of the team. I ask the same questions as above. I collect qualitative and quantitative information, in the form of interviews and surveys. If building out a full system or implementing a piece of it, I run it through my 4 C's Framework. While it applies to the wider Operational Efficiency, it also applies to narrow systems too.

If the system is viable and makes sense to build and roll out, I do this in a non-linear fashion.

Non-Linear Rollout

Rolling out a system, regardless of how small, is a large undertaking for any team. Firstly, I recommend starting with part of the team, if possible. A system rollout should always include synchronous and asynchronous training, with a help hotline of sorts.

The key here is that once a system is live, it should stay in flux until the system is adopted by the majority and you have numerous avid promoters of it. This doesn't mean the system needs to be modified daily, but it does mean that it can and should be changed in some way. Not by being reactive to each request or comment, but through more research.

More Research

After the initial rollout, start more research. Ask the same questions as earlier. Find out if this system is actually solving the problem. It might solve it 100% or only partially — that's ok. Getting these insights early is essential to saving adoption before the honeymoon phase wears off. You don't want users to start their old habits back up, as it is much harder to build support around the system when they have already lost faith in it.

Iteration

Like software development, tool adoption requires iteration. You might build a beautifully designed system that needs to be peeled back. Similar to a writer, most of my work is deleting, rather than adding. Most users don't know what they don't know, but they do know what they don't want or need. By iterating after research, I can save the initial rollout and dramatically increase overall adoption of a system.

To be clear, not all system rollouts are successful. Even with following the steps above, the system might need to be trashed. This is ok, too. As long as you collect insights. This will determine if you need to pivot into another solution or just chalk this rollout up to a learning opportunity.

Change management is hard. I have launched and been part of many failed system launches, but I have also seen them go swimmingly. So don't get discouraged if that new tool or system fell face down. Support the next launch with research and iteration.