The software industry has a dirty open secret, documented for decades: most projects don't go to plan. The Standish Group's long-running CHAOS research has tracked this for over twenty-five years, and the persistent finding is brutal, only a minority of software projects land on time, on budget, with the intended value; the rest run over, get gutted, or die entirely.
Read that again as a buyer: failure is the statistically normal outcome. Walking into a software project without understanding why is walking into a casino that publishes its odds.
Here's the part the statistics hide, though, and it's genuinely good news: the failures aren't random. They rhyme. The same handful of causes appear in postmortem after postmortem, and every one of them is visible before development starts, to anyone who knows where to look. So let's look.
The failure patterns (in the order they actually kill)
1. The problem was never defined, only the solution. The most common death, and it happens in the first meeting. The client arrives with a solution ("we need an app with X, Y, Z") that was never traced back to a user's actual problem. Development executes the feature list faithfully; launch day reveals the list was a guess. The code worked. The premise didn't. Postmortems file this under "poor requirements," which is a polite way of saying nobody ever established what problem the software existed to solve.
2. Scope creep, death by "while we're at it." No single addition kills the project; the pattern does. Each mid-project idea seems small, but every one arrives after architecture was designed for a smaller thing, so each costs more than it would have upfront, delays everything behind it, and (the killer) delays the moment real users can react. Scope creep isn't an enthusiasm problem. It's what fills the vacuum left by failure pattern #1: when nobody defined what the project is, nothing can be ruled out of it.
3. The communication gap nobody bridges. The client speaks business; the developer speaks systems; both nod. Months later the demo reveals they were describing different products the whole time. The gap isn't anyone's fault, it's the default state, and it stays open on projects with no structured translation: no written scope in plain language, no visible progress, no early working versions to react to. Silence between kickoff and delivery isn't smooth sailing. It's the gap, compounding.
4. The big-bang launch. Everything bet on one reveal, after months of building at maximum assumption and zero evidence, the exact inversion the MVP mindset exists to prevent. When the launch-day surprises arrive (they always arrive), there's no budget left to respond to them. The project didn't fail at the end; it failed at the shape, the end just published the result.
5. Success had no definition, so failure had no alarm. No agreed metrics, no "this is what working means," so the project drifts, and drift never announces itself. Projects with a written definition of done can notice trouble at 20% off course. Projects without one notice at 100%, usually via the invoice.
The one question
Everything above compresses into a single diagnostic. Before any code, ask the person who wants the software:
> "Describe the user's problem, without mentioning the app."
Watch what happens.
If they can, "our customers wait four days for a quote because three staff pass a spreadsheet around, and we lose half of them by day two", the project stands on rock. A real problem, in the user's world, with a cost attached. Features can now be derived and disputed against it; scope has a referee; success has a definition (quotes in hours, fewer losses); the communication gap has a shared object on both sides of it. Every failure pattern above just lost its oxygen.
If they can't, if every answer routes back through the solution: "the problem is we don't have the app", stop. Nothing is wrong with this person; something is missing from this project, and it's the foundation. Building anyway means paying developer rates to search for the problem mid-construction, which is the most expensive place it's ever been found.
We ask this question in our own discovery calls, out loud, and we've declined projects on the answer. It's also, fittingly, one of the questions to ask before hiring anyone, because a builder who doesn't ask you for the problem is planning to bill you for the guess.
What this means if you're about to commission software
The odds aren't a coin flip you're stuck with, they're the average of prepared and unprepared buyers, and you get to choose your side before spending anything:
- Write the problem, user's-eye view, no app allowed in the sentence.
- Attach its cost, what does this problem burn per month in money, time, or lost customers?
- Define done, the number or behavior that will prove the software worked.
- Then, and only then, talk features, each one now auditable against the problem.
- Launch small, per the MVP loop, so evidence arrives while the budget can still respond to it.
An afternoon of writing, and you've exited the failure statistics' main population. The research says most projects fail. It doesn't say yours has to volunteer.