The Art of Project Management

7.5. When are specs complete?

For any development schedule that has a planning phase, the writing and reviewing of specifications is its natural conclusion. In theory, the team should know most of the details for what will be built and how it will be done when the specs are complete. The project is ready to go at full speed, and the balance of the work shifts from planners and designers to programmers and testers.

7.5.1. How much is enough?

Deciding when a specification is complete is a judgment call. There are always lingering issues and questions or dependencies on other companies and projects that haven't completely sorted themselves out yet. The "spec complete" stamp of approval can mean very different levels of completeness and quality depending on the project and the team. There's no right or wrong here: sometimes the risk of weaker specifications is outweighed by schedule pressure or other considerations. Just like any other high-level aspect of a project (code quality, stability, performance), only the judgment of team leaders can decide the right level of investment. And, of course, the more iterative the general engineering strategy is, the more flexibility there will probably be in how specifications are written.

But as a universal rule, the stronger the specification is, the greater the probability will be of a timely outcome. The question then is how much probability do you need? Is it worth the time it takes to make a specification 5% better? Or would the programmers ...