The failure mode nobody budgets for
Industry surveys have put the failure rate of large transformation initiatives somewhere between 60 and 70 percent for decades. The number barely moves, and the reason is rarely technical. The software compiles. The vendor delivers. The project closes green.
Then you walk the floor six months later and find the dispatchers back in their spreadsheets.
Operational software doesn't usually fail in production. It fails in the gap between the strategy deck and the shipped system — between the process as leadership believes it works and the process as your operators actually run it.
Decks describe the org chart. Operations run on exceptions.
A strategy engagement produces a model of your operation: swim lanes, handoffs, clean boxes and arrows. The model is usually accurate for the 80 percent of cases that were never the problem.
The value of an operation lives in how it handles the other 20 percent — the rush order, the truck that broke down, the customer who always calls the senior dispatcher directly. That exception handling is undocumented by definition. It lives in the heads of your most experienced people.
Software built from the deck instead of the floor handles the happy path beautifully and breaks on the first exception. Operators learn that lesson in a day. Then they route around the system, the spreadsheets come back, and your new platform becomes an expensive data-entry chore performed after the real work is done.
Top tip
A simple field test: if the people who will use the system daily cannot name the person building it, the requirements were written from the org chart, not the operation.
Three ways to close the gap
Diagnose on the floor, not in the conference room. Requirements gathered in stakeholder meetings describe intentions. Requirements gathered by sitting next to a dispatcher for a week describe reality. The second set is smaller, stranger, and correct.
Ship in cycles short enough to be wrong safely. A system delivered as one big reveal after nine months bets the entire budget on the initial spec being right. Delivering working software every few weeks means a wrong assumption costs you a cycle, not the engagement.
Make adoption the acceptance criterion. A system is not done when it passes QA. It is done when the operators use it without being told to — because it is genuinely faster than the workaround. That standard changes what you build: fewer features, less friction, and relentless attention to the exception cases that decide whether the floor trusts the tool.
The standard to hold
Whether you build in-house or bring in a firm like ours, hold the work to one question: does the metric move? Not "was the deliverable accepted" — did order-to-dispatch time drop, did error rates fall, did the operation get measurably faster.
Strategy decks don't move metrics. Shipped systems that operators actually use do. The gap between the two is where operational software lives or dies — and closing it is a discipline, not an accident.