Advisory
Most software projects solve the wrong problem well
When a software project disappoints, the instinct is to blame the build. More often the build was fine. The problem was chosen badly, and a good team solved it anyway.
Realm Digital
2 min read
A surprising number of projects ship on time, work as specified, and still fail. The code is sound. The team was competent. What went wrong sits further upstream: the thing that got built was not the thing the business needed. The wrong problem was solved, and solved well.
This is the failure that does not show up in a status report. Every milestone is green. The disappointment arrives later, when the software is live and the numbers do not move, and no one can point to a line of code that is broken.
Why the wrong problem gets chosen
By the time a brief reaches a development team, it has usually hardened into a solution. Someone has already decided that the answer is an app, a portal, a rebuild. The brief describes what to build, not what is wrong. The team, doing its job, builds it.
The real problem is often one or two questions further back. A business asks for a customer portal when the actual issue is that support is overwhelmed by a handful of repeated requests. A portal might help. So might fixing three things on the existing site, at a tenth of the cost. Nobody asked, so nobody found out.
Discovery is not a formality
Discovery has a bad name because it is often theatre: a week of workshops that ratify a decision already made. Done properly, it is the opposite. It is the part of the project where the answer is still allowed to change, including to nothing at all.
The questions that matter are unglamorous. What is this costing you today, in money or time? Who feels the pain, and how often? What have you already tried? What happens if we do nothing? The answers routinely reshape the brief, and sometimes retire it.
The test of a good partner
A supplier takes the brief and quotes it. A consultancy asks whether the brief is right first. The difference is not attitude, it is incentive: if you are paid to build, every problem looks like a build.
The most valuable thing a technical partner can tell you is that you do not need what you came to ask for. It is also the hardest thing for them to say, because it costs them the work. Worth listening for all the same.
