Waterfall
How Waterfall Works
Waterfall organizes project work into sequential phases. Each phase has a defined set of deliverables, a completion checkpoint, and formal sign-off before the next phase begins. The metaphor is literal: work flows forward like water down a cascade. Unlike Agile, you do not return to a previous phase once it is complete, at least not without significant cost.
The five standard Waterfall phases are requirements, design, development, testing, and deployment. In the requirements phase, all project scope and functional specifications are documented and approved. In design, the architecture and detailed specifications are created based on those requirements. Development builds the product according to the design. Testing verifies that what was built matches what was specified. Deployment delivers the completed product.
The critical dependency in Waterfall is that requirements must be complete and stable before design begins, and design must be complete before development begins. If a requirement is discovered to be wrong during development, the cost to fix it is substantially higher than it would have been during requirements gathering, because design and development work based on the incorrect requirement must be reworked.
This is not a flaw unique to Waterfall: the cost of change increases as projects progress in any delivery model. Waterfall manages this by investing heavily in upfront definition to reduce the probability of late changes. Agile manages it by designing for continuous change rather than trying to eliminate it.
When to Use Waterfall
Waterfall is appropriate when requirements are genuinely stable and knowable upfront, when the client or regulator requires complete documentation before any work begins, or when the cost of late changes in your domain is prohibitively high.
Construction projects fit Waterfall well: you cannot begin building without a complete structural design, and you cannot easily change the foundation after it is poured. Defense and government contracting often mandates Waterfall-style documentation and phase gates for regulatory and audit reasons. Embedded systems development in regulated industries like medical devices and aerospace uses Waterfall because the verification and validation requirements demand exhaustive pre-specification.
Waterfall is also appropriate when your client relationship is transactional rather than collaborative. A fixed-price contract where the client expects a defined deliverable at a defined date is more compatible with Waterfall than with an Agile approach that requires ongoing client participation in backlog prioritization and sprint reviews.
When Not to Use Waterfall
Waterfall struggles when requirements are uncertain or will change as the team learns more. Software product development is the most common example. Users interact with software, discover what they actually need, and change their requirements accordingly. A two-year Waterfall plan for a consumer software product will almost certainly produce a product that matches the requirements from two years ago rather than what users need today.
Waterfall also struggles when stakeholder feedback is needed before the product is fully built. If showing users a working prototype and incorporating their feedback is more efficient than specifying every detail upfront, Agile’s shorter cycles produce better outcomes at lower total cost.
The most common Waterfall failure mode is discovering a critical requirement error during the testing phase, requiring a rebuild of substantial portions of the development work. This is the risk that exhaustive upfront requirements gathering is designed to prevent, and when it occurs anyway, it produces cost overruns that are structurally harder to absorb in Waterfall than in Agile because there is no iterative checkpoint where the error could have been caught earlier.
Commonly Confused With
| Term | Key Difference |
|---|---|
| Agile | Agile delivers iteratively with evolving requirements and regular stakeholder feedback throughout delivery. Waterfall delivers once at the end with requirements fixed upfront and minimal stakeholder involvement between phases. |
| PRINCE2 → | PRINCE2 is a structured project governance framework with defined stages, roles, and oversight mechanisms. Waterfall is a delivery sequence. PRINCE2 can be used alongside Waterfall (and often is), but they are different things: one is a governance model and the other is a delivery model. |
Common Questions About Waterfall
Is Waterfall still used in 2026?
Yes, widely. Construction, government contracting, defense, pharmaceutical development, and regulated manufacturing all use Waterfall-style sequential project management because their work genuinely requires complete upfront specification and phase-gate sign-off. The narrative that Waterfall has been replaced by Agile is accurate only in software product development, where Agile’s iterative approach produces significantly better outcomes. In physical and regulated industries, Waterfall remains the dominant approach.
What are the five phases of Waterfall?
Requirements gathering, design, development (or implementation), testing (or verification), and deployment (or maintenance). Some models add an initiation phase before requirements and a maintenance phase after deployment. The defining characteristic across all versions is that each phase is completed and formally signed off before the next begins, and returning to a previous phase after sign-off requires a formal change request process.
What is the main criticism of Waterfall?
The most valid criticism is that Waterfall assumes requirements can be fully known before any development work begins, which is rarely true in complex software or product development. Requirements discovered during development that contradict earlier specifications create rework that is expensive precisely because design and development decisions were built on the incorrect foundation. Agile frameworks address this by expecting requirements to evolve and building short feedback cycles into the process.
Can Waterfall and Agile be used together?
Yes. Hybrid approaches are common when different phases of the same project have different characteristics. A common pattern: use Agile methods during the discovery and design phases (short sprints, regular stakeholder review, iterative refinement of requirements), then shift to Waterfall-style sequential execution during the build phase once requirements are stable. Construction firms often use this pattern for complex projects with long pre-construction design phases.