Three Real Specs That Killed a Project (and What They Cost)

September 2, 2026· 8 min read

The point of these three stories is not to gawk at famous disasters. It is to see that all three failed for the same reason: a requirement was ambiguous, missing, or never frozen — and the bill arrived months or years later, multiplied.

Each case has one lesson. Learn all three and you have most of the craft of requirements engineering.

Mars Climate Orbiter — the unit that was never written down

In 1999 NASA lost the Mars Climate Orbiter, a spacecraft worth over a hundred million dollars, during orbital insertion. The investigation found a cause that sounds too small to be true: one team’s software reported thruster impulses in pound-force seconds, while the navigation software on the other side expected newton-seconds.

Two teams, one interface, two unit systems — and nobody had written down which one the interface used. This was not a coding bug. It was an interface specification that was never agreed, so each side made a different, reasonable assumption.

The lesson: an interface is a requirement like any other. Pin down its units, formats, and contracts in writing, because "everyone knows" is exactly how two teams end up disagreeing.

Denver baggage system — complexity nobody agreed to

In the 1990s, Denver’s new airport committed to a fully automated baggage system — thousands of carts on a track network, sorting and routing every bag across the airport. The system was expected to work on day one. It did not. Bags were lost, jammed, and torn. The opening was delayed by 16 months, and the failure cost hundreds of millions of dollars before large parts of the system were abandoned for manual handling.

The requirements problem was not a single bad line. It was a scope that was never realistically specified or frozen: requirements kept growing, the complexity was underestimated, and there was no agreed baseline of what "done" meant before construction began.

The lesson: complexity compounds. A system that is not bounded by a written, agreed scope will grow until it exceeds what anyone can deliver.

FBI Virtual Case File — the spec that never froze

In the early 2000s the FBI tried to replace paper case files with a digital case-management system. After years of work and roughly 170 million dollars, the project was scrapped — it never reached a usable state.

The recurring cause in every post-mortem was the same: the requirements never stopped changing. There was no single authority who could say "this is the specification, and we are building to it." The design chased a moving target until the project collapsed under its own churn.

The lesson: a requirement that keeps changing is not a requirement, it is a suggestion. A project needs a frozen baseline — and a controlled process for changing it — or it will never ship.

The same three mistakes, in every project

Strip away the spacecraft, the airport, and the agency, and you are left with three errors that happen in ordinary teams every week:

An interface or unit that was assumed instead of written down.
A scope that grew because nobody agreed on a boundary.
Requirements that changed without a controlled, recorded process.

You will never build a Mars orbiter. But you will absolutely inherit someone else’s unstated assumption — and the most expensive mistake is the one you are not looking for.