Why Internal Software Goes Unused
A system that nobody opens has not failed technically. It failed at the point where it asked people to work in a way they had already rejected.
Article
Internal tools fail quietly. There is no outage and no complaint. The system is delivered, everyone is trained, and within a couple of months the team is back in the spreadsheet with the new tool open in a tab nobody looks at. The post-mortem usually blames adoption, which is a way of blaming the users. The cause is normally in the specification. It was designed from the org chart Requirements are typically gathered from the people who own the process rather than the people who perform it. What comes back is how the work is supposed to happen. The software then encodes that, and collides on day one with how the work actually happens, including the exceptions everyone has been handling informally for years. The fix is to watch the work rather than ask about it. The gap between the two is where the project succeeds or fails. It asks for more than it gives back Many internal systems are net extractive for the person using them. They ask someone to enter more detail than they used to, and the benefit lands with a manager reading a report elsewhere. People notice this immediately. If a tool costs a user ten minutes and returns nothing to them, it will be abandoned as soon as the pressure to use it drops. Every screen should give the person in front of it something: the answer they were about to look up, the step they were going to have to remember. It was finished before it was used A system specified in full, built in full and delivered in full has had no contact with reality until the day it is too late to change cheaply. By then the decisions are structural. Getting a narrow version into real use early is uncomfortable, because it is visibly incomplete. It is also the only way to find out which of the specified features nobody actually wanted, which is usually a larger fraction than anyone expects. Nobody owned it after launch Business processes change continuously. A system that cannot change with them starts drifting out of alignment the week it launches, and a tool that no longer matches how the work is done is worse than no tool, because it is actively misleading. Internal software is not a project that finishes. It needs someone who can change it, and a route for the people using it to say what is wrong. Without both, the drift only runs one way.