Written By
Share This Article
It's Tuesday, 11:47 PM. Your top-performing rep is in his car in a hospital parking lot, finishing the day's cases on the spreadsheet he's used since 2019. The system you spent millions deploying nine months ago is open in another tab. He'll update it tomorrow. Maybe.
That is what a failing implementation actually looks like. Not just a broken system. A rep who is still working around it, because it wasn’t designed for them.
The instinct is to scrutinize the technology. Was the integration tight? Was the configuration optimized? In most cases the honest answer to both is: maybe. The platform works as designed. The data seems to flow. The system does exactly what it was built to do: feed the organization's appetite for data.
Meanwhile, the reps are doing exactly what they were trained to do: get the right implants and instruments to the right case, on time, and keep the surgeon covered. They are doing it well. They are also doing it while carrying a new obligation to a system they could have told you wouldn't work, if anyone had asked. Nobody did.
From there, the story writes itself. The reps use the tool because they are told to, but never fully embrace it. It adds a few minutes to every case, then a few more, until the day they have to choose between feeding the system and doing their actual job. They choose to serve the surgeon and patient. They do it again the next day, and every day after. The data turns to noise, the millions spent either get written off or become a sunk cost that keeps on growing, the reps get blamed for low adoption, and twelve months in, someone apologizes for an initiative that was never going to work.
None of that is a only change-management failure. It is a design failure.
Most tools are engineered around the organization's appetite for data instead of the sales rep's reality in the field. So, the real question is not whether the app works. The question is whether a tool the rep won't use can be said to work at all.
An app the rep won't use, is a tool no amount of change management can rescue.
The right platform is built the other way around. It starts from the rep's reality and earns its data by making the job easier, which is the only reason a rep ever truly adopts anything. But even the right tool doesn't change behavior on its own.
That is where change management comes in: not to rescue the wrong platform, but to get the most out of the right one.
The Right Bridge Nobody Was Trained to Cross
Imagine you built a bridge that goes exactly where people need to go. State of the art, six lanes, millions to construct, and the ROI model says it pays for itself inside eighteen months. On opening day, you notice half the commuters are still swimming across the river.
The bridge isn't broken. Nobody was trained to drive on it. Driver training was never on the project plan, and it was never in the budget. So now you have a beautiful, expensive, half-empty bridge and a community of strong swimmers who are very proud of how fast they swim across the river.
That’s implementation failure, and it’s a gap that no amount of engineering can close.
That gap is the change management work. Deploying a platform and getting hundreds of people to change how they work are two different projects, with different scope and different timelines. Both have to run. Run them as one and you ship the system on Friday, find out on Monday that the project team has already rolled off, and discover in month seven that the change-management work nobody owned is now a problem nobody can overcome.
What Getting This Wrong Actually Costs
When a field inventory implementation underdelivers, the financial damage is rarely dramatic. It's gradual. A rep who never fully adopted the system still completes her cases, just more slowly and with more manual workarounds than before. A division that was never brought into the original decision, still manages its inventory, just not in a way that feeds clean data back into the platform. An organization that declared victory at go-live stops measuring against the value objectives it set twelve months earlier.
None of that looks like failure from the outside. Internally, it compounds. Across hundreds of reps and dozens of divisions, the gap between what the implementation was supposed to deliver and what it actually delivers becomes a real number. That number shows up in excess inventory nobody can account for, in emergency shipments that should have been prevented, and in administrative burden still sitting on the people who were told the tool would lift it.
Stryker's Jason Henderson, Director of Mako Business Process, put it plainly on a recent webinar with Movemedical Chief Customer Officer Ted Ruscitti and Rubica's Sue Gordon: “Field reps don't underperform because of talent. They underperform because the systems around them create friction faster than anyone can work through it. Field rep productivity falls as administrative burden climbs."
Those are not only technology issues, and they aren’t a talent problem. They’re what the wrong tool and an unmanaged rollout produce together, and the operational alibi keeps the real cause hidden.
How Adoption Erodes When You Skip the Work
The organizations that get this right treat the platform decision and the adoption work as two efforts, not one. Choose a system built for the rep, then do the deliberate work of moving people onto it. Skip either half and the result looks the same from the outside: a semi-functioning tool nobody fully uses.
From there the erosion is predictable. Users who were never bought-in adopt the system selectively. Selective adoption produces inconsistent data. Inconsistent data undermines the visibility and control the platform was supposed to create, and the ROI case built on that visibility erodes while everyone assumes the other team is handling it.
The Alignment Problem Most Organizations Skip
Jason Henderson built buy-in for field inventory transformation by doing something most leaders in his seat skip: He brought customer service, operations, clinical, sales, and IT into one room and asked and showed them how the change would actually support their jobs day to day. Not whether they supported the initiative.
Asking for support of the initiative gets you conceptual buy-in that looks great on a slide. Asking how the change will affect daily workflow gets you a real implementation plan, one that surfaces whether the tool actually fits the work before the contract is signed, and accounts for the barriers before they surface. The first is wishful thinking. The second is change management.
What Henderson learned: the field doesn't resist change because it hates change. It resists because nobody translated the executive ROI case into a number the reps could see themselves in. The business case was crystal clear at the top and invisible at the rep level.
Sue Gordon at Rubica calls this a distributed accountability problem. The ROI is real, but the accountability for delivering it sits concentrated at the top of the organization, where the reps can't reach it. The rep who can't see her contribution to the goal has no reason to change how she works to hit it.
Breaking ROI down by role, by division, and by year is not a communications exercise. It is a structural one. When people can see themselves in the number, accountability follows. When they cannot, even the right platform will underdeliver.
The Process Problem Nobody Wants to Talk About
There’s a harder conversation underneath all of this, and organizations avoid it because it adds time to an already demanding project.
The question isn’t whether the system can handle your current process. It almost certainly can. The question is whether your current process is worth automating.
In most field organizations the answer is more complicated than anyone wants to admit. Reps invented workarounds to compensate for the old system. Divisions built local variations on processes that were supposed to be standardized. Customer service built manual bridges between platforms that didn't talk to each other. None of that shows up in a demo. All of it shows up the moment a new system processes it at scale.
Implementing a platform on top of a fragmented process doesn't fix the fragmentation. It accelerates it. You get a faster version of the same problem, and worse data coming out the other side.
The work of defining the gold-standard process has to happen before configuration begins. What does good look like in the field? What are the non-negotiables across divisions, and what are the legitimate variations the system needs to accommodate? What behaviors have to change before the technology can deliver the visibility it promises? Those questions are harder than scoping an integration, they take longer to answer, and they are the ones most likely to get deferred in favor of hitting the go-live date.
Scope Creep Is a Governance Problem, Not a Scope Problem
Once an implementation is underway, the pressure to expand scope is constant and almost always well-intentioned. A division wants a feature that wasn't in the original build. A stakeholder surfaces a use case discovery missed. A temporary workaround gets encoded into the configuration because nobody made the call to fix the underlying process instead.
Each decision looks reasonable in isolation. In aggregate, they’re how focused, high-value deployments drift into sprawling projects that are months behind schedule and well over budget before anyone flags it.
The fix isn’t a harder line on scope. It’s a governance structure that routes every change request back to the original goal before it gets built: a formal decision-making framework, a strong internal lead who owns the plan, and the willingness to look a good-faith stakeholder in the eye and say no when the answer is no.
Flexibility isn't the enemy, and adaptation matters. What kills the ROI is adaptation without a governance frame. That's scope drift in a customer-success costume.
Go-Live Is Where the Work Starts
The final mistake, and the most costly one at scale, is treating go-live as a finish line.
The data coming out of the system in the first months after deployment is a diagnostic, not a report card. It shows which user groups adopted fully, which adopted partially, and which are still running shadow workflow ops from the parking lot. Organizations that measure that data and act on it protect their ROI. Organizations that declare victory and move on find out twelve months later that the value they projected never materialized.
Partial adoption is not just a training gap. It is a data-integrity time bomb. Users who complete some steps and skip others feed inconsistent inputs into every downstream decision. Inventory positions distort. Billing reconciliation gets harder. The visibility you bought the platform for disappears into the gaps the half-adopters left behind.
The organizations leading this space, Stryker among them, treat post-go-live engagement as a continuous discipline rather than a hypercare phase with an expiration date. They measure adoption by user group, watch for decline, and intervene before it entrenches. That requires data infrastructure, a customer-success relationship that doesn't roll off at go-live, and a commitment to treating the implementation as a long-term asset rather than a completed project.
What This Actually Requires
The change-management frameworks are well understood. The integration playbooks exist. What almost no vendor delivers is the thing the rest depends on: a platform built around the rep in the field rather than the org chart above him. That platform is the precondition. The discipline to protect adoption after go-live is what gets the most out of it. Most organizations are missing a partner who brings both.
That is what Movemedical was built to do, and the Blueprint Immersion process is built around the exact failure modes above. The alignment gap is closed before a contract is signed, through executive alignment and stakeholder interviews across IT, sales, ops, customer service, and auditing. The process trap is addressed by defining the gold-standard workflow and a risk register before configuration begins, not after. Scope drift is contained by a change-control governance frame that ties every request back to the value case. And the go-live cliff is replaced by a delivery team that doesn't roll off at launch, so adoption gets measured and protected when it actually matters.
Movemedical's numbers come from the platform and that work together: 20-plus ERP integrations, 14 million-plus surgeries supported, and 98 percent adoption across some of the most complex commercial organizations in MedTech. Reps adopt at those rates because the software was built for how they actually work, and because the adoption work was done at the human level, in parallel with the build, by people who stayed accountable past go-live.
Your implementation went live nine months ago. It's 11:54 PM, and your top rep is still in the parking lot. The platform did everything it was built to do. It was just never built for him.
If your implementation is live but your ROI is not, the gap is recoverable, but only if you diagnose it accurately. Schedule a 20-minute executive walkthrough to see exactly where your operation is leaking value and what it will take to close it.
