Tim Lockie
Before you migrate to a new tool, find out whether the last one failed as a system or as a culture. If you skip that step, the new tool inherits the same failure.
Here's what you'll learn:
What they actually found
Why this happens to almost everyone
The system-or-culture question, and how to actually answer it
Write the non-negotiables before you take the demo
Practical takeaways
Before you sign, run these five questions
I watched a team make this call last week, and it was the right one.
The operations group at Furniture Bank, a nonprofit I work with, was ready to move their request management into a new system. Reasonable move. The tool they had been using was not catching the work. Requests were getting lost, nobody could see status, and the team was tired of it.
Then somebody asked the question that stopped the meeting. Did the last tool fail because of what it could not do, or because of how we used it?
They paused the migration to answer it.
What they actually found
The tool they had, Linear, is a genuinely good piece of software. It did not fall over. It did not lack features. When the team looked honestly at what happened, the failure was organizational: adoption barriers, and a culture where most of the organization did not live in that tool.
That distinction matters more than it sounds. Linear works fine at Furniture Bank for the people who work in it every day, and it is still in use. What failed was Linear as the FRONT DOOR for the whole organization. It was never the wrong tool. It was the wrong place to ask everyone to show up.
What does that mean? If they had migrated on the original timeline, they would have carried the same adoption problem into a new system, paid for the privilege, and burned the team's patience on a second rollout that failed for the first rollout's reasons.
The reframe they landed on is the useful part. The question is not "which tool is best." It is "where does this organization already talk to itself." At Furniture Bank the answer was the tool where organizational communication already happens, so that became the leading candidate rather than them going with the flashiest option.
Why this happens to almost everyone
This is not a Furniture Bank problem. It is close to the default.
Across enterprise software, user adoption is the single most common cause of failure, ahead of any technical shortcoming. CRM projects fail somewhere between 20 and 70 percent of the time, and poor adoption tops the list of causes. On the ERP side, most research puts the share of implementations that miss their original objectives somewhere between 55 and 75 percent. These are not projects that broke because the software did not compile. They are projects where the software worked and the organization did not move.
The money follows the same pattern. Recent 2026 license data puts the share of SaaS seats that are unused or barely used at roughly half or more, with one analysis finding around 66 percent of licenses either untouched or surplus to what the organization actually needs. Nobody buys shelfware on purpose. It accumulates when tools get purchased to solve a problem that was never correctly diagnosed.
And when project managers are asked why things failed, inaccurate requirements gathering lands near the top of the list, cited in roughly 37 percent of cases in PMI's research. Which tracks. If you never wrote down what the thing had to do, you had no way to know whether it did it.
All that to say: buying is easy, diagnosing is not, and the industry numbers are what happens when you do the easy one first.
The system-or-culture question, and how to actually answer it
The diagnosis is not complicated, it is just uncomfortable, because half the time the answer implicates the rollout rather than the vendor.
A SYSTEM failure means the tool could not do the job. Feature gaps, no reporting, will not integrate, does not scale. Real, and the fix is a different tool.
A CULTURE failure means the tool could do the job and people did not use it. Nobody made it the default, the work happened somewhere else, leadership never modeled it, the training landed months before the real work started, or the people doing the work were never asked what they needed. The fix there is not a different tool. It is adoption, and a new purchase will not touch it.
Most failures are the second kind wearing the first kind's clothes, because "the tool was bad" is a much more comfortable story than "we didn't make it work."
Here's the thing that makes the diagnosis honest: you have to do it BEFORE you fall in love with the replacement. Once the demo is booked, everything you find will get bent toward the decision you already made.
Write the non-negotiables before you take the demo
The other half of what that team did right, and the part most people skip, was writing down what the next system has to do before evaluating anything.
Not a wish list. Non-negotiables. Furniture Bank's list came out of the failure they had just diagnosed, which is exactly where a good list comes from. They needed conversation in context, meaning discussion attached to the actual record rather than scattered in a chat channel that loses the thread. They needed reporting and visibility good enough to see whether a request actually got completed. And they needed to respect that one of their teams was not going to live in the new tool daily, so that team needed visibility pushed to where they already were.
Notice that every one of those requirements is a scar. Each one names something that hurt. That's what makes them non-negotiable rather than aspirational, and it's why the diagnosis has to come first. You cannot write a real requirements list until you know what's broken.
They also deferred the final decision to a broader organizational conversation about tool adoption, which sounds like a delay, but it's actually the whole point. The tool decision was never a tooling decision.
Practical takeaways
- Before you evaluate a single replacement, write one sentence answering whether the last tool failed on capability or on adoption, and make yourself defend it with evidence.
- Check whether the outgoing tool is genuinely unused or just unused by SOME people, because "it works for the team that lives in it" changes the problem from replacement to routing.
- Ask where your organization already communicates by default, and treat that as a serious candidate even if it is less impressive than the alternatives.
- Turn every failure you found in the diagnosis into a written non-negotiable requirement, and cap the list at five so it stays real.
- Book the demos only after the requirements are written down, so the evaluation tests the tool against your list instead of against the vendor's pitch.
- Name who has to change their daily behavior for the new tool to work, and if that number is large, budget for adoption work rather than assuming the rollout covers it.
- Say out loud what happens to the requests that are in flight during the switch, because that gap is where trust in the new system gets lost in week one.
Before you sign, run these five questions
Take these into your next leadership meeting and answer them honestly before anyone signs anything:
- Can we say, with evidence, whether the last tool failed on features or on adoption?
- Who was actually using it, and did we ask them what they needed before deciding to replace it?
- What are the three things the next system absolutely has to do? And write them down, before a demo.
- Where does our organization already talk to itself every day, and could that tool be the answer?
- If we change nothing about how we roll this out, what makes us think adoption will go differently this time?
If question five makes you wince, that's your answer, and it's fixable. It just is not fixable by purchasing.
The tool swap is not the project. The diagnosis is the project. Do that part and the tool choice mostly makes itself.
-t
