Postmortem: The $60,000 Software Rollout That Changed Nothing
CONTINUOUS IMPROVEMENTPROCESS IMPROVEMENT
9/26/2026
This postmortem is an illustrative composite, assembled from patterns documented across implementation research and the rollouts we're asked to rescue. The statistics cited are real.
Subject
Field-service management platform, 45-person commercial services company
Investment
$38K license + implementation, ~$22K internal time — $60K total
Objective
Replace spreadsheets + paper tickets; give real-time job visibility
Outcome
Abandoned at month 9. Spreadsheets still in use. Profit impact: zero.
Timeline of the failure
WEEK 0
Owner sees the platform demoed at a trade show. The demo is excellent — everything he's been frustrated by for three years, solved on one screen. He signs within eleven days, motivated by a year-end discount. No requirements were written; no current process was mapped; the crews and dispatcher were not consulted.
WEEK 3
Data migration begins. The customer list, built over nineteen years across two spreadsheets and one former employee's memory, turns out to contain duplicates, inconsistent addresses, and equipment records that exist only as handwritten notes in job folders. The implementation partner asks for "clean data." Nobody owns producing it.
WEEK 7
Go-live, announced by email, scheduled in the company's busiest month. Training is one 90-minute session for everyone, delivered as a feature tour. Crews are told to enter jobs in the app "as well as" the existing paper tickets during transition — a parallel-running period with no end date attached.
WEEK 9
Adoption splits. Two younger techs use it fully; the dispatcher uses it partially; the three senior techs — who produce most of the revenue — do not, because the app takes longer than their clipboard and nobody has shown them what it does for them. The system now contains partial data, which means its reports are wrong, which means the office stops trusting them.
WEEK 14
The dispatcher, needing one reliable source of truth, rebuilds the old spreadsheet "temporarily" to cover the gaps. It becomes the real system again within a fortnight. The platform is now a $38,000 duplicate data-entry burden.
WEEK 22
Owner raises it in a management meeting. The consensus is the diplomatic version of "the software doesn't fit our business." Nobody says the accurate version: nobody was ever made responsible for it working, and no one's job changed to accommodate it.
MONTH 9
Subscription cancelled at renewal. Verdict recorded internally: "wrong software." Verdict recorded here: the software was never the variable.
Root causes
1 It was bought as a product, not adopted as a change
The dominant finding across implementation research: 60%+ of failures trace to people-related causes — adoption resistance, unclear ownership, weak change management — while only about 6–10% are attributable to problems with the software itself. This rollout had a purchase plan and no change plan, which is the modal failure, not an unusual one.
CRM implementation research, 2026; Panorama Consulting 2025 (68% ERP failure rate)
2 The users who mattered most were consulted last
Poor user adoption is cited by roughly 70% of companies as the leading cause of implementation failure — and it is overwhelmingly a design consequence: people reject systems that feel like data entry imposed for management's reporting benefit rather than tools that make their own day easier. The three senior techs weren't obstinate. They were correct that, as configured, the app cost them time and gave them nothing.
CRM implementation challenge research (70% cite adoption as leading cause)
3 Dirty data was discovered, not planned for
Poor data migration and data quality rank among the top three causes of implementation failure across thousands of studied projects. Nineteen years of informal records is not an edge case; it's the normal starting condition of an established SMB — and it needs an owner, a budget, and a schedule of its own, decided before signature rather than discovered in week three.
ERP failure research — top three causes account for 75%+ of failures
4 Go-live was scheduled for the worst possible month
Go-live timing is an executive decision, not an IT detail — the most famous enterprise implementation disasters on record trace directly to launching during peak season. A busy month guarantees that the first friction encountered becomes a permanent reason to revert, because nobody has slack to climb a learning curve while firefighting.
ERP implementation case-study research on go-live timing and governance
5 Parallel running with no end date guaranteed reversion
Letting the old system continue "during transition" without a hard cutover date is the operational equivalent of leaving the exit door open in a burning building — everyone takes it. The old system is faster because it's familiar; without a date that removes it, familiarity wins every time, and the new system decays into optional double work.
Change-management research on adoption and system cutover
The protocol that would have prevented it
Before signing: map the current process and write down what specifically must be true for this to be worth $60K — three measurable outcomes, not "better visibility." Involve the people who will use it daily in the demo and the selection; their objections before purchase are free, and after purchase are fatal. Assess data quality honestly and budget the cleanup as a named project with an owner.
During rollout: assign one internal owner accountable for adoption (not the vendor, not "IT" — a person whose performance includes this). Configure for the user's benefit first: what does this do for the technician on a wet Tuesday? Train by role, in short sessions, on real jobs — not one feature tour for everyone. Recruit two respected super-users from the skeptical group rather than the enthusiastic one. Go live in a quiet month. Set a hard cutover date and remove the old system on it.
After go-live: measure adoption weekly for the first quarter — percentage of jobs entered, not percentage of licenses assigned — and treat a dip as a design problem to diagnose rather than a discipline problem to scold. Publicly connect the system to wins ("we caught that warranty claim because it was logged"). And hold one honest review at ninety days against the three outcomes written before purchase.
The reason this postmortem matters beyond software: the same pattern governs every operational change a small business attempts — the new process, the new role, the new reporting rhythm. Tools don't change businesses; adopted tools do, and adoption is a management project with an owner, a date, and a measurement. Buy that, or the license is just an expensive receipt for an intention.
Contact
Let's improve your business together.
contact@rmscsolutions.com
© 2026 All rights reserved.
Contact
+1 647-576-7000