You've invested in the system. You've had it built, or configured, or at least set up to a point where it should work. You've explained it to the team. And then... people slowly drift back to their old ways. The spreadsheet gets reopened. The WhatsApp thread becomes the default again. The new tool sits there, technically operational, but practically unused.

Change management is one of the most common operational frustrations I see in my fractional COO work and it's almost never the team's fault.

Why teams don't adopt new systems

Before looking at what to do, you need to understand why this happens.

The usual culprit is that the new system doesn't reflect how the team actually works because it was built around a template, or because the person building it didn't take the time to map out the actual process beforehand. 

When a new system adds steps rather than eliminating them, when the workflow inside the tool doesn't match the actual process, people find their own way around it, because the workaround is faster.

The second most common culprit is inadequate training. You need more than a walkthrough on launch day. You need the kind of training that covers why it's structured the way it is, what it's replacing, and what good usage actually looks like in practice. A team that understands the logic of a system uses it more consistently than a team that has only been shown the buttons. The training also needs to showcase see a real example inside the new process so they can see how much simpler it is.

The third culprit is the absence of visible leadership commitment. If the people leading the team aren't using the system themselves and instead still making decisions inside conversations that bypass it or still asking for updates by email rather than checking the tool, the implicit message is that the system is optional. Teams are very good at reading that signal.

The change management piece most implementations skip

Most system implementations focus on the technical side like the build, the configuration, the data migration. The change management side gets less attention, and that's usually why the team doesn't get stuck in.

When it comes to new systems, change management isn't a soft concept. It's the practical work of moving a team from one way of working to another in a way that sticks. It involves a few specific things that most implementations don't include.

Involving the team before the system is built. The teams that adopt new systems most readily are the ones who had some input into how they work. Not necessarily into the technical decisions, but into the process decisions such as what they find frustrating about the current way of working, what they need the new system to do, what would make it easier to use. When people have been heard in the design of something, they're more invested in making it work.

Communicating the why, not just the what. A team that's told "we're moving to ClickUp on Monday" is less prepared than a team that's told "here's what's been frustrating about how we work, here's what we're building to fix it, and here's how it will change your day to day." The reason matters. People who understand why a change is happening are more willing to tolerate the learning curve that comes with it.

Making the old way harder than the new way. If the old spreadsheet is still accessible and still feels easier than the new tool, people will use it. At some point (not on day one, but once the new system is working properly) the old way needs to be unaccessible. Not deleted necessarily, but archived or restricted. The new system has to become the path of least resistance, not just one of several options.

Designating a champion inside the team. An external consultant or fractional COO can build a system and train a team, but the person who answers questions on a Tuesday afternoon about it is someone inside the business. Identifying that person early -someone who is comfortable learning the new tool, trusted by their colleagues, and willing to support adoption - is one of the highest-leverage steps in any implementation.

The role of the leader in system adoption

In my fractional COO work, one of the first things I look at when a team isn't using a system properly: what the leadership behaviour around it looks like.

Team adoption of a new system almost always follows leadership behaviour. If the leader checks the tool, references it in meetings, asks questions by pulling up the relevant view rather than asking someone to tell them, the team notices. If the leader sends an email asking for an update on something that's tracked in the system, or makes a decision in a side conversation that should have happened in the project management tool, the team notices that too.

The signal leaders send about whether a new system is genuinely the way we work now, or whether it's a nice-to-have that sits alongside the actual way we work, is one of the most powerful factors in whether adoption happens.

What to do when adoption is already failing

If you've already launched a system and the team isn't using it, the instinct is often to either push harder or give up. Neither is usually the right answer.

Pushing harder with more reminders, more insistence, more frustration expressed in team meetings rarely improves adoption and often damages morale. The team knows the system exists. The problem isn't awareness; it's that the system isn't working for them in some way that hasn't been identified yet.

Giving up by accepting that the team won't use it and returning to the old ways solves the immediate tension but leaves the underlying problem in place. The operational debt continues to accumulate. The next attempt at change will face the same resistance, compounded by a team that has learned that new systems don't stick.

The more productive approach is to go back to diagnosis. Talk to the team to genuinely understand where the friction is. Where does the system not match how they work? What step feels unnecessary? What does the workaround do that the system doesn't?

The answers will usually reveal either a configuration problem (something in the system that can be adjusted) or a training gap, or a process that hasn't been properly mapped into the tool. Any of those is fixable.

Building a culture where systems stick

Beyond any individual implementation, there's a longer-term question about what kind of operational culture a business is building.

Teams that adopt new systems readily tend to have a few things in common:

1. There's a shared understanding that how we work is something we actively improve.
2. New tools and processes are introduced with proper context and genuine training, not dropped on people with a deadline.
3. Feedback is welcomed and acted on, which means people trust that raising a problem with a system will result in a fix.

That culture doesn't happen by accident; it's built through consistent leadership behaviour, through taking change management seriously as a discipline, and through having someone with operational responsibility who thinks about these things continuously rather than only when a specific problem surfaces.

This is one of the most valuable things an ongoing fractional COO engagement provides: the sustained operational leadership that makes those systems stick and evolve as the business grows.

A practical diagnostic

If you're currently facing a team that isn't using a system the way it was intended, here's a simple diagnostic to start with: Ask three people on the team, separately, what they find frustrating about the system. Don't defend it. Just listen. The pattern in their answers will tell you more about why adoption is failing than any amount of usage data.

Then ask yourself honestly: how consistently am I using it? What message does my own behaviour send about whether this system is the real way we work?

The answers to those two questions will almost always point to the next step.

Sustainable system adoption is one of the things an ongoing fractional COO engagement is specifically designed to support, ensuring they stick, evolve, and continue to serve the business as it grows. Find out more about working with Systems Rani as a fractional COO or get in touch to talk through where your business is.