Why New Software Goes Unused

Six months after launch, the new system contains only part of the story. The old spreadsheet is still open on someone’s desktop, and it is the version people trust.

When leaders ask why new software goes unused, the usual answer is resistance to change. The staff using the spreadsheet may see it differently. The new tool takes longer. It leaves out something they need. It organizes information around a report they never read. It asks them to change a process that worked without giving them anything useful in return.

People rarely create workarounds because they enjoy having one more place to put information. They create them because the approved workflow gets in the way of the job they are trying to do.

That is why new software goes unused. Many adoption problems are design problems that were settled long before launch.

The workaround is also your best clue. If your team is already working around a tool, I’ll show you how to watch them and what to change once you see why.

The workaround usually makes sense to the person using it

At one hospital system, employees captured notes and saved information in their own Google Docs and other informal tools instead of using the approved system.

Leadership thought staff simply didn’t want to follow the process. But the approved tools made it hard to find information, capture a quick note, or keep important details close at hand. Staff were working under time pressure in a high-stakes environment. They used whatever helped them finish the job.

Their workaround may not have been the right organizational solution, but it was a rational response to the way the system worked.

This distinction matters. If you treat the behavior as defiance, you reach for stronger mandates. If you treat it as evidence, you ask what the workaround makes easier.

The answer often points directly to the adoption problem.

A familiar workflow can still contain a bad assumption

Even a design based on an existing process can fail if it reproduces the wrong part of that process.

Back at a prior firm, I worked on a project for healthcare providers to build a self-service tool that gave physicians access to scientific information held by pharmaceutical companies. Previously, a physician would call a contact center, ask a specific question, and receive a specific answer. The company could not simply provide all of its documentation without a request.

Search seemed like the natural digital equivalent. A physician could type a question instead of asking it over the phone.

When we watched people use the product, we found the flaw in that assumption: physicians didn’t know what information was available, so they didn’t know what to search for. The tool asked them to formulate questions they had never been able to ask before.

We couldn’t remove search because access to the most meaningful content still required a specific request. Instead, we added ways to orient people. The interface showed the kinds of content and products covered in the database, and it allowed some browsing within each product. Users could understand the breadth of what was available before deciding what to search for.

The constraint stayed intact. The experience around it changed.

Look for adoption problems before launch

One useful warning sign is the amount of novelty in the proposed workflow.

If the new process preserves most of how people already work and improves a few important steps, that is encouraging. If nearly every step is new, the rollout is introducing a new tool, a new process, and new habits at the same time. Each change creates another place for friction or confusion.

The bigger warning sign is a workflow designed without the people expected to use it.

Ideally, a frontline staff member serves as a regular contributor to the design team. When that isn’t possible, create recurring touchpoints during early design sprints, and test proposed workflows before too much has been built. Let people experience the process in the context of their actual day while there is still time to change it.

That is the practical difference between gathering reactions and co-creating a system. Showing staff a finished product and saying, “Look at this great thing we built for you,” gives them no meaningful role in shaping it.

Our advice to stop guessing and start with user evidence applies to internal tools as much as customer-facing products.

Can training get staff to use new software?

It can help as part of a considered rollout. It can’t repair the workflow.

People need time to orient themselves to a new tool. A gradual transition can give them room to learn while making the direction clear. The old system might remain available at first. Later, it becomes reference-only, with all new information entered into the replacement. At a final cutoff point, the old system goes away.

Used this way, a mandate creates a timeline for adoption. It doesn’t force people to perform their jobs through a process that does not work.

You can often tell the difference by looking across the team. If some people are using the new system successfully while others struggle, more learning or support may be needed. If nearly everyone fails at the same point or avoids the same part of the process, the workflow deserves scrutiny.

Widespread failure is not a training plan waiting to happen.

Give the person doing the work something back

Too many internal tools are designed primarily for the person reading the report rather than the person entering the data.

Better reporting matters, but it should be a secondary benefit of helping frontline staff do their jobs well.

Imagine a counselor meeting with someone who needs support. The system should make it easy to capture the necessary information while allowing the counselor to stay present in the conversation. It should give that person more time for the human work only they can do, rather than pulling their attention toward a screen.

A good tool should work like a power tool in a carpenter’s hands: it helps a skilled person complete the work faster and more precisely.

That visible return changes the reason to adopt the software. Staff are no longer entering information only because leadership needs a report. The tool is helping them do the work they are accountable for.

We saw a version of this in our work with 4MyCiTy. A participant described the benefit as being able to “track how much we save and help us see what we actually get.” The same platform also gives leaders real-time reports, but the value is visible to the person using it. Read the 4MyCiTy story.

A champion should promote real value, not police compliance

An internal champion can make a meaningful difference in adoption. Their job is to keep explaining what the system will enable, how it will help people, and what the future state looks like when the team uses it consistently.

The strongest champions act as steady advocates. They repeat the purpose of the tool in leadership conversations and organization-wide communication. They help people understand why the change matters, especially before those benefits are obvious through experience.

They are not the usage police.

A champion also cannot compensate for a poor implementation or a workflow that makes no sense. The value they promote has to be real. Otherwise, the message quickly loses credibility.

If staff already work around the tool, watch them

Start with someone you trust who is good at their job and still struggles to use the system as intended. That combination matters. You aren’t looking for the least engaged employee. You are looking for evidence of where a competent person and the approved workflow come apart.

Before observing them, ask what they find difficult and what the tool doesn’t let them do. Then watch them complete the relevant task more than once. The first session may feel awkward. By the second or third, the person is more likely to settle into their normal behavior, and patterns become easier to see.

Pay close attention whenever they leave the defined workflow. If they can explain what they are doing while they work, let them. If thinking aloud would be distracting, take notes without interrupting, and ask afterward:

What made you leave the system at this point?
What prevented you from completing the task in the approved workflow?
What did your workaround make faster or easier?
What does your approach allow you to do that the system does not?

The goal isn’t to catch someone breaking the rules. It is to understand the job their workaround is doing.

Make the smallest change that solves the problem

Once you understand why people avoid the tool, work from the smallest intervention to the largest.

Fix the workflow when the tool already supports what people need and the process changes are minor.

Reconfigure the tool when the default setup doesn’t reflect how your organization works. An out-of-the-box configuration is a starting point, not an operating model.

Replace it with another product when the original buying process did not account for users’ needs and a better-fit option exists. This can be difficult when the organization has already invested money and credibility in the current tool.

Build custom software only when the need is genuinely distinctive, no existing product provides the necessary functionality, or serious security and data-privacy constraints rule out available tools.

There is one complication. A familiar tool can be easier to repair because people already know it. But if poor experiences have destroyed trust, persuading staff that “it works now” may be harder than introducing something new.

Our build-versus-buy guide can help you evaluate that decision. If the problem is part of a broader pattern, these 10 warning signs that you have outgrown your systems offer another place to start.

Sometimes you already own the right software

A nonprofit arts organization came to me because it was struggling to manage projects, keep work on task, and clarify what was coming next and who owned it. The organization wondered whether it needed different project-management software.

The larger problem was how the existing tool was being used.

We introduced project templates and standard documents with placeholders for the information each engagement needed. Those prompts helped people remember what to consider at the beginning of a project. We also established a regular reporting cadence, guidelines for defining and assigning tasks, recurring task reviews, and an organization-wide review of project status.

Owning a tool doesn’t make work more organized. The organization still has to decide how people should use it together.

In this case, the honest answer was not new software. It was a clearer way of working with the software already in place.

Build around the people expected to use it

If your staff keep returning to a spreadsheet, a personal document, or a handwritten note, don’t begin by asking how to make them comply.

Ask what that workaround gives them that the approved system does not. Watch where they leave the intended process. Count how many new behaviors the system demands. Find out whether the person entering the information receives any value in return.

Then make the smallest change that addresses what you learned.

Adoption doesn’t end at launch, either. Launch is the halfway point, and the first months of real use will show you what to change next. That’s the work Product Stewardship is built for.

The software that gets used is the software built around its users.

Got a tool your team works around? Tell us how it works today. We’ll help you figure out why, even if the answer isn’t new software.