What does a bad spec really cost?

Nobody can put one reliable number on the cost of a bad spec, because it shows up as rework, delay and value that doesn't arrive, spread across many budgets. But the research that exists points the same way. In a 2014 survey, the Project Management Institute (PMI) found that 5.1 percent of every dollar spent on projects and programs was wasted because of poor requirements management, about $51 million for every $1 billion spent.

The rest of this page sets out what the better-known studies actually say, and where their limits are.

Where does the money go?

Mostly into three places:

• Rework. Something is built as written, then turns out to be wrong, and has to be built again. The work is paid for twice, and the second time is usually harder because other parts now depend on it.
• Delay. A developer stops to ask a question nobody can answer quickly, or a disagreement between departments surfaces halfway through the build and has to be settled before work can go on.
• Missed value. The software ships late, ships without the part that mattered, or isn't used because it doesn't fit how the work is really done. That cost doesn't appear on any invoice.

What does the research say?

• PMI, 2014. When projects missed their original goals, inaccurate requirements management was the primary cause almost half of the time (47 percent). The same survey put the waste from poor requirements management at 5.1 percent of project spending. It's a survey of practitioners, and it covers projects of every kind, not only software.
• CISQ, 2022. The Consortium for Information & Software Quality estimated the cost of poor software quality in the U.S. at at least $2.41 trillion in 2022. That includes about $260 billion for unsuccessful development projects and about $607 billion for finding and fixing defects. Poor requirements are one cause among many in those figures, not the whole of them.
• NIST, 2002. A study prepared for the National Institute of Standards and Technology estimated that an inadequate infrastructure for software testing cost the U.S. economy $22.2 billion to $59.5 billion a year. It's useful history, but it's more than twenty years old and is about testing, not specifications.

Isn't a defect 100 times more expensive to fix later?

That claim is repeated widely, but we don't use it. The data usually cited for it is decades old. A 2017 study of 171 software projects found no consistent evidence that issues cost more to fix the later they were resolved. Late fixes can still be expensive, especially when other work has been built on top of the mistake, but there is no reliable multiplier to quote.

What does that mean for my project?

The useful question is smaller than any national estimate: how many of your developer's questions could be answered before the build starts? Every question answered up front is one that doesn't stall a sprint, and every disagreement settled on paper is one that doesn't have to be rebuilt. Results vary with the project and the people.

You can see which questions an existing document leaves open with the free spec check, or read what a build specification covers.