Autopsy #11: The Change Management Afterthought
Cause of death: the entire session proved the system worked, and none of it proved anyone would use it.
Ninety minutes of demo. Every module clicked through, every workflow shown, every objection about functionality answered on the spot. Then, in the last five minutes, someone asks about training and adoption, and the presenter says something reassuring and short: “the interface is intuitive, users pick it up quickly,” maybe gestures at a slide with a generic icon of people around a laptop, and the meeting ends on schedule.
Nothing in those ninety minutes tested the only variable that determines whether an ERP implementation actually pays off: whether the several hundred people who currently do their jobs a certain way will actually do them a different way starting on a specific Monday morning. That variable got five minutes and a slide. Everything else got ninety.
What actually happened
A demo is, by construction, a test of the system in isolation. It shows what the software can do when operated by someone who already knows exactly which buttons to press, in exactly the right order, with no muscle memory pulling them back toward the old way of doing things. That’s a test of the product. It says almost nothing about the much harder problem sitting underneath every ERP rollout, which is that the system doesn’t fail because it can’t do the work. It fails, when it fails, because the people who were supposed to start using it on day one didn’t, or did so inconsistently, or found a workaround that quietly recreated the old process inside the new tool.
The demo cannot show this risk because the risk doesn’t live in the software. It lives in a warehouse supervisor who has run the same process for eleven years and has a system that works well enough for them, a controller who doesn’t trust the new close process until they’ve watched it succeed three months running, a data entry team that will, absent enforcement, keep using the spreadsheet they built in 2019 because it’s faster for them personally even if it creates downstream problems for everyone else. None of that shows up in a screen share. All of it shows up in the first ninety days of production.
Why it works on smart people
Functionality is legible in a way that adoption risk isn’t. You can watch a screen and evaluate, with reasonable confidence, whether a feature does what it claims to do. You cannot watch a screen and evaluate whether the accounts payable team, specifically, at your company, specifically, will actually change how they process an invoice exception, because that isn’t a property of the software being demonstrated. It’s a property of an organization that isn’t in the room.
Because functionality is the thing that’s easy to evaluate in real time, it naturally consumes the meeting. Evaluators default to spending their scrutiny where scrutiny is possible to apply, and adoption risk, being diffuse, organizational, and only observable months later, gets the leftover attention at the end of the agenda, not because anyone decided it mattered less, but because there was no way to spend ninety minutes evaluating it the way there was for the features.
There’s also a comforting assumption doing a lot of quiet work: that a system good enough to buy will be a system people are willing to use. That assumption is often wrong in a specific, predictable direction. The features that make a system good for the business, tighter controls, more required fields, more visible audit trails, are frequently the exact features that make individual users’ jobs feel harder in the short term, which is precisely the friction that produces workarounds and shadow processes.
The actual damage
This is the failure mode that shows up as an implementation that technically went live and never actually delivered its business case. The system works. The training happened, in the generic sense that sessions were held and attendance was tracked. And six months later, half the intended users are still keeping a parallel spreadsheet, a workaround team has formed around one specific process nobody bothered to redesign for the new tool, and the data quality problems the new system was supposed to fix are still there, because garbage still goes in whenever someone routes around the system instead of through it.
Nobody can point to a single moment this failed. It failed gradually, in a thousand small individual decisions to keep doing things the old way, none of which showed up as a defect, an error, or a support ticket, because from the system’s point of view nothing went wrong. The people just didn’t come.
The fix, if you’re the one presenting, or the one buying
Treat adoption as a first-class item in the evaluation, not a closing slide. Ask the vendor, specifically, what happens to the specific roles in your organization who will feel the most friction from the new process, not the roles who benefit most. Ask what the actual training plan looks like beyond a generic session count, and who owns reinforcement after go-live, when the temptation to slide back into the old process is highest. If you’re the one presenting, bring a real adoption story, with a real friction point that was anticipated and addressed, instead of a slide with a stock photo and the word “intuitive.”
A system that works and a system that gets used are not the same claim, and only one of them was tested in that room.
This is exactly the gap I dug into in Gamification of ERP: Turning Drudgery into Dopamine. Points and badges won’t fix a bad rollout, but the underlying problem, that a system’s success depends on individual motivation, not just individual capability, is precisely the variable this autopsy argues nobody tests before go-live.
A Tinkerers Notebook 