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 been using since 2019. The platform you spent $2M deploying nine months ago is open in another tab.
He'll update it tomorrow... maybe.
This is what a failing implementation looks like. Not a broken system, but a rep who's still working around it.
Your instinct to scrutinize the technology makes sense: Was the platform the right choice? Was the integration tightened? Was the config optimized?
The honest answer to all three is usually yes. The platform works. The data flows. The system does exactly what it was built to do. The people don't.
And that's not a problem the platform can solve.
15% drop in field rep productivity after a major implementation. 35% climb in administrative burden in the same six months. Those aren't technology metrics. They're change-management failures with an operational alibi, and leadership teams who confuse the two will spend the next two quarters looking for the answer in the wrong system.
Imagine you built a bridge: State of the art, six lanes, modern engineering, $2M to construct, and the ROI model says it pays for itself inside eighteen months. But on opening day, you notice that half the commuters are still swimming across the river.
The bridge isn't broken—It's that nobody was trained to drive on it. Driver training wasn’t on the project plan, and it wasn’t in the budget. Now you're left with a beautiful, expensive, half-empty bridge, and a community of strong swimmers who are very proud of how fast they cross the river.
That's a failed implementation.
Implementation and Adoption Are Different Projects
Deploying a platform and getting hundreds of people to change how they work are two different projects. Different scope, different timeline, and both projects need to run.
Run them as one project and you'll ship the system on Friday, find out on Monday that the project team's already rolled off, and discover in month seven that the change-management work, which never had an owner, is now a problem nobody owns.
Stryker's Jason Henderson called this out on a recent webinar with Movemedical's CCO Ted Ruscitti and Rubica's Sue Gordon.
Before Stryker committed to field inventory transformation, Henderson did something most leaders in his seat would skip: He put customer service, operations, clinical, sales, and IT in a room together pre-contract, and asked them what the platform change would actually do to their jobs day to day. Not whether they supported the initiative.
Asking for support of the initiative gets you conceptual and idealistic buy-in that looks great on a PowerPoint. Asking “How will this change affect your daily workflow?” gets you a comprehensive implementation plan that thoroughly assesses your current operational reality and accounts for potential barriers and pitfalls.
The first is wishful thinking.
The second is change management.
Here’s what Henderson learned: the field doesn't resist change because they hate change. They resist because nobody translated the executive ROI case into a number the reps can see themselves in.
The business case may be crystal clear at the top, but it is invisible at the rep level.
The Accountability Gap Behind Failed Adoption
Sue Gordon at Rubica calls this a distributed accountability problem. The ROI is real, but the accountability for delivering it sits where your reps can't reach it. And the rep who can't see her contribution to the goal has no reason to change how she works to hit it.
Multiply that across hundreds of reps and dozens of divisions, and the gap shows up later: in excess inventory nobody can account for, in emergency shipments that should've been preventable, and in the administrative burden still sitting on the people who were promised the tool would lift it.
Stop Automating Broken Processes
Now the harder question:
Forget whether your new platform can handle your current process. It almost certainly can.
The honest question is whether your current process is worth automating.
In most field organizations, the answer is “no”. Reps invented independent 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, but all of it shows up the moment a new system processes it at scale.
To guarantee your $2M implementation underdelivers, skip the process work and just deploy on top of whatever you already have.
You won't, because that story has a predictable ending: a faster version of the same problem, but with worse data.
Define what good looks like before configuration. Not after. Not in parallel.
Scope Creep Is a Governance Problem
A close cousin to the process trap is scope creep. The industry consistently mis-diagnoses the process trap as a scope problem, when it's a governance problem.
When every reasonable-sounding change request gets approved without routing back to the original value case, implementations drift from focused deployments into sprawling, over-budget projects.
The fix is structural: a governance frame that ties every change back to the goal, an 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, but what kills the ROI is adaptation without a governance frame — it's scope drift in a customer-success costume.
Go-Live Is the Diagnostic, Not the Finish Line
Go-live is the diagnostic, not the finish line.
The data coming out of your platform in the first six months tells you which user groups adopted fully, which adopted half-fully, and which are still running shadow workflow ops from the parking lot.
Selective adoption may only look like a training gap, but it's also a data integrity time bomb.
Half-workflows feed inconsistent inputs into every downstream decision: inventory positions distort, billing reconciliation gets harder, and the visibility you bought the platform for disappears into the gaps the half-adopters left behind.
The organizations leading change-management discipline, Stryker among them, treat post-go-live as a continuous practice, not a hypercare phase with an expiration date.
They measure adoption by user group. They watch for decline. They intervene before decline entrenches.
What Change Management Looks Like in Practice
Movemedical's Blueprint Immersion is built around this exact framework: executive alignment, stakeholder interviews across IT, sales, ops, customer service, and auditing, edge case identification, risk register, and change-control governance — all done before configuration begins, with a delivery team that doesn't roll off at go-live.
What most organizations are missing is a partner who treats the human side of implementation with the same rigor as the technical side, and who stays accountable to the value case after the project team has moved on.
The Platform Was Never the Gap
Movemedical's numbers tell that story:
- 20+ ERP integrations.
- 14M+ surgeries supported.
- 98% field rep adoption across some of the most complex commercial organizations in MedTech.
That doesn't just come from the technology being excellent, it also required the change management work to be done at the human level.
Your implementation went live nine months ago. But today it's 11:54 PM, and your top rep is still stuck in the parking lot.
The platform was never the gap. Get a 20-minute call with our team to learn how you can create a better tomorrow with a better implementation.
