Waterfall project management is a linear, sequential methodology where work flows through fixed, consecutive phases — each phase must be fully completed before the next begins. Originating from manufacturing and construction industries, it was formally described by Dr. Winston Royce in 1970 and remains widely used in predictive, plan-driven environments with stable requirements. Unlike iterative approaches, Waterfall emphasizes upfront planning, comprehensive documentation, and formal approval gates at each phase boundary, making it ideal for projects where scope, budget, and timelines are well-defined early. The methodology's hallmark challenge is its resistance to change once a phase is complete — modifications require formal change control processes and can cascade backward through completed work. Understanding Waterfall's structured milestones, dependency management, and rigorous handoff protocols is essential for delivering large-scale projects where predictability and traceability outweigh the need for flexibility.
What This Cheat Sheet Covers
This topic spans 16 focused tables and 112 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core Project Phases
Each phase in Waterfall produces formal deliverables that act as inputs to the next, creating structured handoffs that demand sign-off before work progresses. Getting phase boundaries right — especially the transition from requirements to design — determines whether downstream phases stay on track or spiral into rework.
| Phase | Example | Description |
|---|---|---|
Stakeholder interviews, document analysis, Business Requirements Document (BRD) | • Captures all functional and non-functional requirements upfront before design begins • stakeholders sign off on scope baseline before next phase starts. | |
High-level architecture diagrams, technical specifications, database schema design | • Translates requirements into technical blueprints, including system architecture, UI mockups, and integration designs • reviewed and approved by technical stakeholders. | |
Coding modules per design specs, building infrastructure, configuring environments | • Developers build the solution according to approved design documents • no design changes should occur without formal change control. |