Waterfall is a sequential approach to project management where each phase — requirements, design, build, test, release — is completed and signed off before the next one starts.
The idea
Waterfall plans the whole project upfront and moves through fixed phases in order, treating each as a gate: once a phase is done, work flows downstream to the next and rarely flows back. This fits work where requirements are well understood in advance and change is expensive to accommodate mid-project, such as physical construction or regulated systems where rework late in the process is costly or unsafe.
When to use it
- Requirements are stable, well understood, and unlikely to change materially
- The cost of changing course late in the process is high (construction, hardware, regulated industries)
- Stakeholders need a fixed scope, timeline, and budget agreed upfront
How to apply it
- Gather and document complete requirements before design begins.
- Complete the design phase fully before build starts.
- Build, then test as a distinct phase once build is complete.
- Release only after testing signs off, treating each phase transition as a formal gate.
Watch out for
Waterfall assumes requirements gathered at the start stay correct throughout the project; when they don’t, discovering the mismatch late (in testing) is the most expensive place to find it. It also gives stakeholders no working output to react to until very late, so misunderstandings compound silently.
Related models
- Agile — the iterative approach that developed largely as a reaction against waterfall’s rigidity.
- Scrum — a specific agile framework often contrasted directly with waterfall.
- Critical Path Analysis — a scheduling technique commonly used within a waterfall plan.
Sources
Winston W. Royce, “Managing the Development of Large Software Systems” (1970) — often cited as the origin of the waterfall description, though Royce’s paper actually critiqued a purely sequential process.