Serge BelovThe most common reason software projects go over budget isn't bad developers. It's under-specified requirements that force expensive rework mid-build.
A technical specification is a written agreement on what you're building before you build it. It sounds obvious. Most projects skip it anyway.
What a spec actually is
A specification isn't a 100-page waterfall document. A useful spec for most projects is 5–20 pages that answer:
- What problem are we solving? Stated in terms of user behavior, not features
- Who are the users? With enough specificity to make design decisions
- What does the system do? Functional requirements, edge cases, constraints
- How does it work? Data models, API contracts, integration points, auth flows
- What does it not do? Explicit scope boundaries are as important as scope inclusions
- How do we know it's working? Acceptance criteria for each major feature
The economics
A requirement change during specification costs an hour of discussion. The same change during development costs days of rework. The same change after launch can cost weeks and affect live users.
This is Boehm's Law, formalized in the 1970s and still empirically true. The cost of change compounds at every stage of development. Front-loading the hard decisions is the highest-leverage thing you can do before a project starts.
What makes a spec bad
Most specs that fail do so because they describe solutions instead of problems. "The system will have a dropdown with the following options" is a solution. "Users need to filter results by region to find relevant listings" is a problem. Solutions embedded too early in a spec lock in bad design decisions before anyone has written a line of code.
The other common failure: specs written by one person without developer input. The people who will build the system will catch ambiguities, technical constraints, and edge cases that no product owner anticipates alone.
The spec as contract
A finished specification serves as the baseline for project estimates, milestones, and change management. When a stakeholder asks for something new mid-project, the spec is the document you refer to. "That's not in scope — here's what is, and here's what adding it would cost."
Without a spec, every conversation about scope is a negotiation from scratch.
When to write one
Any project with more than one developer, more than two weeks of work, or more than one stakeholder needs a spec. Smaller projects benefit from even a one-page decision log.
The time it takes to write a good spec is always less than the time it saves.