I built the right system. Half the company never picked it up.
This is the case study most consultants would not publish. I am publishing it because what it taught me is worth more to you than a clean win would be.
A binder, a spreadsheet, and the person who remembered
A crawler and heavy-equipment rental and sales business, running across a Texas office, a Texas yard, and a parts operation in Mississippi. Parts, purchasing, rentals, equipment records, bills of lading, transport, service and lease agreements all lived in paper forms, spreadsheets, and in the heads of the people who had been there longest.
I spent the discovery phase collecting the actual artifacts — the carbon-copy forms, the inventory sheets, the inspection forms — and modelled the system on how the work genuinely moved rather than on how it was supposed to.
What one department did with it
The system went live in June 2024 and rolled out to iPads in the field. In the parts and purchasing module, where there was someone who wanted it to work, it did:
Purchase orders, equipment records and bills of lading came off carbon-copy forms and onto the system, and that team has not gone back. What I know about how much it is actually used comes from reading the production database directly, not from a dashboard built to flatter the project.
Where no one owned it, it went quiet.
Modules built for service, transport and rentals were used for a while and then stopped. Not because they were wrong, and not because anyone was lazy. The people who had championed them moved on, and no one inherited the job of making sure the thing was actually used.
I take the first share of that. What they bought was a build, and builds end. At go-live I moved to support and no one was left driving adoption — which is a gap in how the engagement was shaped, not a failure of the people using it.
Software does not fail at the build. It fails after go-live.
When they later asked me to extend the service module with new features, the honest answer was no — not yet. That module did not have a feature problem. It had an adoption problem, and building on top of it would have addressed something that was not wrong.
This is why the engagements I take now do not end at delivery, and why I would rather tell you not to build something than sell you a module no one opens.
Ask me about this one on a call
I will tell you what went wrong as readily as what went right, because the failure mode here is the single most common way operations software wastes money — and it has nothing to do with the software.