4 min read
Four ways internal software dies
The dashboard that became a nicer morning report, the spec written in a conference room, the big-bang launch, the vendor who left. One cause.
Most abandoned internal tools were not badly built. They were built to the request, and the request was already a translation. “We need a dashboard for late orders” is what someone says after months of pulling a report every morning, highlighting rows and emailing three people. Build the dashboard and you get a nicer morning report. Nothing upstream changes. That is the first of four ways it dies.
The request is not the problem
The dashboard is one possible answer. The actual problem is that nobody finds out an order is going to be late until it already is. Software that faithfully delivers the request fails when the request was the wrong target, and the request usually is: it describes the workaround someone has settled into rather than the step that broke.
Nobody watched the work
Specifications get written in conference rooms. The people in the room know the process as it is supposed to run. The people who run it know the exceptions: the supplier whose invoices always arrive with the wrong PO number, the receiving clerk who photographs damaged pallets on a personal phone because there is nowhere else to put them, the scheduler who keeps a paper list of which crews cannot work together.
None of that reaches the spec. The software ships, handles the clean case, and is quietly abandoned in the first month, because the exceptions are the job. If you have ever seen a new system running alongside the old spreadsheet six months after launch, this is why.
Big-bang launches
The next pattern is the long build followed by a single go-live. Months of development, two weeks of training, a cutover weekend. By the time anyone outside the project team touches the software, every decision is already baked in. Feedback arrives all at once, from everyone, at the moment it is most expensive to act on.
Big launches also change too much at the same time. If the new order-exception process, the new screens and the new reports all arrive together, nobody can tell which part is causing the trouble, so the whole thing gets blamed.
No one stays after go-live
The last pattern is the handover. The vendor finishes, documents, trains and leaves. The operation keeps changing: a new product line, a new customer with different packing rules, a warehouse reorganization. The software does not change with it. Small gaps open, people work around them, and within a year the tool describes an operation that no longer exists.
Internal IT usually inherits this, with no context and a full plate. The fix they can afford is keeping the lights on. Improvement stops.
What fixes it: watching the work
The common thread in all four failures is distance between the people building and the people working. So the fix starts by removing it. Before we write a line of code, an engineer joins your team on video calls and watches the work over screen share and camera: the receiving line, the invoice queue, the scheduling board. They pull the data, measure how long things take and how often they go wrong, and report back what they saw, not what they were told.
That is what our Discovery is. It takes up to three weeks, for a fixed fee credited toward the Build, and produces a map of the operation and a ranked list of what to build, with a success measure for the first piece.
What fixes it: early use
The second fix is to put the software in people’s hands early and in small pieces. The first release handles the most common case, for one team, and goes into real use within weeks. The exceptions get added as they show up, in the order they matter. The team learns the tool gradually, and the builders learn the operation the same way.
That is why our Builds are fixed in scope and shipped in stages. The fixed scope keeps the project honest; the stages keep it in contact with reality.
What fixes it: staying on
The third fix is not leaving. The same engineers who built the tool keep running it: hosting, monitoring, fixes, and reserved engineer days each month for whatever the operation needs next. Every quarter we look at what changed and propose the next build. Evolve is a 12-month term, with a buy-out option that gives you the code outright to take in-house.
Software that fits an operation is not something you buy once. It is maintained the way the operation is maintained: continuously, by people who understand it. That is the whole difference.