Defining and Sequencing Waterfall Model Phases
This skill teaches you how to structure the core waterfall model phases — requirements, design, implementation, verification, and maintenance — with clear entry criteria, deliverables, and exit criteria so each phase completes fully before the next begins.
To define and sequence waterfall model phases, identify the five core stages — requirements, design, implementation, verification, and maintenance — then establish explicit entry criteria, deliverables, and exit criteria for each. Phases execute strictly in order; no phase begins until the previous phase's exit criteria are formally approved through a phase gate review. This ensures traceability and prevents costly downstream rework.
Outcome: You can confidently decompose any waterfall model project into well-defined, properly sequenced phases with unambiguous criteria that prevent scope leakage and phase overlap.
Prerequisites
- Basic understanding of software development lifecycles
- Familiarity with the waterfall methodology concept
- Understanding of project scope and stakeholder roles
Overview
The waterfall model is built on a deceptively simple idea: finish one phase completely before starting the next. In practice, however, most waterfall projects fail not because the model is flawed, but because teams never clearly define what 'finished' means for each phase. This skill closes that gap by teaching you how to structure each phase with explicit entry criteria, key activities, deliverables, and exit criteria.
Defining and sequencing waterfall phases is the foundational skill of the Waterfall methodology. Without it, downstream activities like creating project plans and Gantt charts or conducting phase gate reviews have no anchor. When phases are poorly defined, teams experience scope creep between stages, ambiguous handoffs, and the dreaded 'we thought that was done' conversations late in the project.
This skill is especially valuable for project managers, product owners, and technical leads working on projects with stable, well-understood requirements — the exact environment where the waterfall model excels. By the end, you'll have a repeatable framework for structuring phases that any stakeholder can understand and any reviewer can audit.
How It Works
The waterfall model works by enforcing a strict sequential flow where each phase acts as a self-contained stage with defined inputs and outputs. Think of it like a manufacturing assembly line: raw materials (requirements) enter at one end, and a finished product exits the other. No station starts work until the previous station signals completion.
Each phase serves a specific purpose in this chain:
- Requirements captures and documents what the system must do.
- Design translates requirements into a technical architecture and detailed specifications.
- Implementation builds the system according to the design.
- Verification tests the built system against the original requirements.
- Maintenance addresses issues and enhancements after deployment.
The critical mechanism that makes this work is the entry/exit criteria pair. Entry criteria define the preconditions a phase needs before work can start (e.g., 'all requirements signed off by stakeholders'). Exit criteria define what must be true before the phase is considered complete (e.g., 'design document reviewed and approved, traceability matrix updated'). These criteria are enforced through phase gate reviews, which are formal checkpoints where stakeholders approve the transition.
This structure creates a chain of accountability: every deliverable is traceable back to a requirement, every design decision is documented before code is written, and every test case maps to a specification. When done well, the waterfall model produces comprehensive documentation and predictable timelines — which is why it remains the standard in regulated industries, government contracts, and infrastructure projects.
Step-by-Step
Step 1: Identify and Name Your Phases
Start by selecting the phases appropriate for your project. The canonical waterfall model uses five phases — Requirements, Design, Implementation, Verification, and Maintenance — but real projects sometimes split or merge phases. For example, Design might split into High-Level Design (architecture) and Low-Level Design (detailed module specs), or a hardware project might add a Fabrication phase between Implementation and Verification.
List each phase in sequential order. Give each a clear, unambiguous name that your entire team and stakeholders will recognize. Avoid jargon-heavy names that only one discipline understands. The phase names will appear on your Gantt chart, in your project plan, and in every status report, so clarity matters.
Tip: Keep the number of phases between 4 and 7. Fewer than 4 usually means phases are too large to manage effectively. More than 7 creates excessive overhead from gate reviews.
Step 2: Define Entry Criteria for Each Phase
For each phase, document the specific conditions that must be true before that phase can begin. Entry criteria answer the question: 'What do we need in hand before we start this work?'
For the Requirements phase, entry criteria might include: project charter approved, stakeholders identified, and budget allocated. For the Design phase: requirements specification document signed off, traceability matrix initiated. For Implementation: design documents approved, development environment provisioned, coding standards documented.
Be specific and measurable. 'Requirements are done' is not an entry criterion. 'Requirements Specification v1.0 approved by Product Owner and all Section Leads, with no open Priority 1 TBDs' is an entry criterion. The more precise your entry criteria, the fewer arguments you'll have at gate reviews.
Tip: Create a simple table for each phase with columns: Criterion, Responsible Party, Evidence/Artifact. This makes gate review meetings dramatically faster.
Step 3: Define Key Activities and Deliverables
For each phase, list the primary activities the team will perform and the deliverables those activities produce. Activities are the work; deliverables are the tangible outputs.
For example, in the Design phase, activities might include: architectural trade study, database schema design, API contract definition, and UI wireframing. Deliverables would be: System Architecture Document, Database Design Document, API Specification, and UI Wireframe Package.
Every deliverable should be a named artifact with a clear owner and a review/approval process. This is critical because deliverables become the entry criteria for the next phase. If your Design phase doesn't produce a formal API specification, your Implementation team has nothing concrete to build against — and you've broken the waterfall model's chain of traceability.
Tip: Number your deliverables (e.g., D-DES-001: System Architecture Document). This numbering scheme makes traceability matrices and change requests much easier to manage later.
Step 4: Define Exit Criteria for Each Phase
Exit criteria are the conditions that must be satisfied before a phase can be declared complete and the next phase can begin. They are the mirror image of the next phase's entry criteria, but they focus on quality and completeness of the current phase's work.
Strong exit criteria include both completion checks and quality checks. For the Requirements phase: 'All requirements have unique IDs, all requirements are testable, requirements document has been reviewed by all stakeholder groups, and all review comments have been dispositioned.' For the Verification phase: 'All test cases executed, all Priority 1 and 2 defects resolved, test summary report approved by QA Lead.'
Avoid exit criteria that are purely procedural ('review meeting was held'). Focus on substantive conditions ('review meeting was held AND all action items from the review have been closed').
Tip: Include a 'no open blockers' criterion for every phase. This catches the common situation where a review technically happened but critical issues were deferred without resolution.
Step 5: Map Dependencies and Handoffs Between Phases
Now that each phase has its own entry criteria, activities, deliverables, and exit criteria, map how they connect. Draw a simple flow diagram showing which deliverables from Phase N become inputs to Phase N+1.
This dependency map serves two purposes. First, it validates your criteria: if Phase 3 (Implementation) needs a database schema, you can verify that Phase 2 (Design) actually produces one. Second, it identifies handoff points where information or artifacts transfer between teams or roles.
For each handoff, document: what artifact is being transferred, who is responsible for producing it, who receives it, and what format it should be in. Handoff ambiguity is one of the most common sources of waterfall project failure.
Tip: Use a RACI matrix at each handoff point. The person Responsible for producing the deliverable and the person Accountable for accepting it should never be the same individual.
Step 6: Establish Phase Gate Review Checkpoints
Between each phase, insert a formal gate review. This is where stakeholders evaluate the phase's exit criteria, inspect deliverables, and make a go/no-go decision for the next phase. Gate reviews are the enforcement mechanism that gives the waterfall model its rigor.
For each gate, define: who attends (decision makers vs. advisors), what artifacts are reviewed, what the possible outcomes are (approve, approve with conditions, reject), and what happens on rejection (rework scope, timeline impact).
Gate reviews should be scheduled in your project plan with sufficient lead time for reviewers to read the deliverables. A gate review where participants haven't read the materials is theater, not governance. For more detail on running effective gates, see conducting phase gate reviews.
Tip: Send deliverables to reviewers at least 3-5 business days before the gate review. Include a review checklist so reviewers know exactly what to evaluate.
Step 7: Document Everything in a Phase Definition Document
Consolidate all of the above into a single Phase Definition Document (PDD). This document becomes the authoritative reference for how your waterfall project is structured. It should include: the ordered list of phases, entry criteria for each, key activities for each, deliverables for each, exit criteria for each, dependency map, and gate review procedures.
The PDD should be reviewed and approved by the project sponsor and key stakeholders before the project begins. It effectively becomes your project's constitution — the rules everyone agrees to follow.
Store the PDD in a location accessible to all team members and reference it in your project kickoff. When disputes arise about whether a phase is 'really done,' the PDD is the arbiter.
Tip: Version-control the PDD. If you need to modify phase definitions mid-project, treat it as a formal change request through your [change management process](/methods/waterfall/managing-change-requests-in-waterfall).
Examples
Example: E-Commerce Platform Rebuild Using the Waterfall Model
A mid-size retailer is rebuilding their e-commerce platform. The project has a fixed budget, a hard launch date tied to a seasonal sale, and integrations with three external payment providers whose APIs are stable and well-documented. The CTO has chosen the waterfall model because requirements are well-understood and the external dependencies have fixed contracts.
The project manager defines five phases:
Phase 1: Requirements (Weeks 1-4)
- Entry: Project charter approved, stakeholder list finalized
- Activities: Stakeholder interviews, user story mapping, payment API review, requirements writing
- Deliverables: Software Requirements Specification (SRS), Requirements Traceability Matrix (RTM) v1.0
- Exit: SRS approved by Product Owner, CTO, and Payment Team Lead; all requirements have unique IDs and acceptance criteria; no open P1 questions
Phase 2: Design (Weeks 5-8)
- Entry: SRS v1.0 approved, RTM v1.0 baselined
- Activities: Architecture design, database modeling, API contract design, UI/UX wireframes
- Deliverables: Architecture Document, DB Schema, API Contracts, Wireframe Package
- Exit: All design docs reviewed and approved; RTM updated to link requirements → design elements; architecture validated against performance requirements
Phase 3: Implementation (Weeks 9-16)
- Entry: All design documents approved, dev environments provisioned, CI/CD pipeline configured
- Activities: Frontend development, backend development, payment integration, database implementation
- Deliverables: Source code (in version control), unit test results, build artifacts
- Exit: All modules built per design specs, unit test coverage ≥ 80%, no P1 build failures, code review completed for all modules
Phase 4: Verification (Weeks 17-20)
- Entry: All code delivered, unit tests passing, test environment mirrors production
- Activities: Integration testing, system testing, UAT, performance testing, payment end-to-end testing
- Deliverables: Test Plan, Test Cases, Test Execution Report, Defect Log, UAT Sign-off
- Exit: All test cases executed, zero open P1/P2 defects, UAT signed off by Product Owner, performance benchmarks met
Phase 5: Maintenance (Week 21+)
- Entry: Production deployment complete, monitoring dashboards live, support runbook delivered
- Activities: Bug fixes, monitoring, patch releases, knowledge transfer to support team
- Deliverables: Support Runbook, Incident Response Procedures, Monthly Health Reports
- Exit: (Ongoing) Quarterly review of support metrics against SLAs
Gate reviews are scheduled at weeks 4, 8, 16, and 20. The Phase Definition Document is reviewed and approved by the CTO and Product Owner before work begins.
Example: Defining Phases for a Regulatory Compliance Project
A medical device company needs to develop embedded firmware for a new patient monitoring device. The project must comply with IEC 62304 (medical device software lifecycle), which mandates documented evidence of phase-based development. Regulatory auditors will inspect phase artifacts during the FDA submission.
The engineering lead maps IEC 62304 requirements directly onto waterfall model phases:
Phase 1: Software Requirements — Produces a Software Requirements Specification traceable to the system-level risk analysis. Exit criteria include: all requirements classified by safety class (A, B, or C), hazard analysis cross-referenced, and requirements reviewed by the regulatory affairs team.
Phase 2: Architectural Design — Produces Software Architecture Document with module decomposition. Exit criteria require that each module's safety classification is documented and that the architecture supports the fault-tolerance requirements identified in Phase 1.
Phase 3: Detailed Design — Produces detailed design specifications for each module. Exit criteria: every requirement traces to at least one design element, design review completed with clinical engineering present.
Phase 4: Implementation and Unit Verification — Source code with unit tests. Exit criteria: 100% unit test coverage for safety-class C modules, static analysis tool run with zero critical findings, code review for all safety-critical paths.
Phase 5: Integration and System Testing — Full integration test, system-level testing against requirements. Exit criteria: complete RTM showing requirement → design → code → test traceability, all tests passed or deviations formally justified.
Phase 6: Release and Maintenance — Regulatory submission package assembled, post-market surveillance plan in place.
This six-phase structure (splitting the canonical Design into Architectural and Detailed Design) directly satisfies the auditor's need to see documented evidence at each stage. The Phase Definition Document includes IEC 62304 clause references for each exit criterion.
Best Practices
Write entry and exit criteria that are binary — either satisfied or not. Avoid subjective criteria like 'design is sufficiently detailed' in favor of measurable criteria like 'all modules in the design document have sequence diagrams and interface definitions.'
Keep each phase owned by a single accountable person (Phase Lead), even when multiple teams contribute. This prevents the diffusion of responsibility that causes deliverables to slip through cracks.
Build a requirements traceability matrix (RTM) from day one and update it at every phase transition. The RTM is the connective tissue that links requirements → design elements → code modules → test cases, and it's what auditors and regulators look for first.
Time-box your gate reviews. A well-prepared gate review should take 60-90 minutes. If it's taking longer, it usually means deliverables weren't reviewed in advance or exit criteria were ambiguous.
Include a 'lessons learned' capture as an exit criterion for the final phase (Maintenance handoff). This closes the feedback loop and improves your phase definitions for future waterfall projects.
Align your phase definitions with any regulatory or contractual requirements early. In industries like aerospace (DO-178C) or medical devices (IEC 62304), phase structure isn't optional — it's mandated.
Common Mistakes
Defining vague exit criteria like 'requirements are complete' without specifying what completeness means
Correction
Replace vague criteria with specific, verifiable conditions: 'All requirements have unique IDs, are testable, have been reviewed by all stakeholder groups, and all review comments have been dispositioned with no open Priority 1 items.'
Allowing phases to overlap by starting the next phase before the current phase's gate review is approved
Correction
Enforce gate reviews as hard checkpoints. If schedule pressure tempts you to overlap phases, document the risk formally and get sponsor approval. Unauthorized overlap undermines the entire waterfall model's traceability and creates rework downstream.
Skipping the Maintenance phase definition because 'we'll figure it out after launch'
Correction
Define Maintenance phase entry criteria, support processes, and transition procedures during project planning. The handoff from the development team to the operations/support team is one of the highest-risk transitions and must be planned, not improvised.
Creating identical phase structures for every project regardless of size or complexity
Correction
Tailor the number of phases, depth of deliverables, and formality of gate reviews to the project's risk profile. A 3-month internal tool doesn't need the same phase rigor as a 2-year regulated medical device project. Scale the waterfall model to fit.
Treating the Phase Definition Document as a one-time artifact that never gets updated
Correction
When scope changes or new constraints emerge, update the PDD through your formal change request process. An outdated PDD is worse than no PDD because people make decisions based on incorrect assumptions.
Other Skills in This Method
Conducting Phase Gate Reviews
How to run formal gate reviews at the end of each Waterfall phase to validate deliverables, secure stakeholder sign-off, and authorize progression to the next phase.
Building Content Waterfall Strategies
How to apply the Waterfall approach to content production by cascading a single asset into multiple formats and channels in a planned, sequential workflow.
Running Structured Testing and Verification Phases
How to plan and execute systematic testing — unit, integration, system, and acceptance — as a dedicated phase that validates all requirements before deployment.
Managing Change Requests in Waterfall Projects
How to evaluate, document, and process scope change requests through a formal change control board without derailing the sequential project plan.
Creating Waterfall Project Plans and Gantt Charts
How to build detailed project schedules with milestones, dependencies, and resource allocations using Gantt charts and work breakdown structures for Waterfall projects.
Analyzing SEO Waterfall Charts for Page Performance
How to read and interpret browser waterfall charts to diagnose page load bottlenecks, optimize resource loading order, and improve Core Web Vitals for SEO.
Writing Comprehensive Requirements Documents
How to gather, document, and freeze detailed requirements specifications before design begins, ensuring completeness and traceability throughout the project.
Frequently Asked Questions
How many phases should a waterfall model project have?
The classic waterfall model has five phases (requirements, design, implementation, verification, maintenance), but you can split or merge phases based on project complexity. Most projects work well with 4-7 phases. Fewer creates unmanageable phase sizes; more creates excessive gate review overhead.
What is the difference between entry criteria and exit criteria in the waterfall model?
Entry criteria define what must be true before a phase can start (e.g., approved requirements document). Exit criteria define what must be true before a phase is considered complete (e.g., all test cases passed). Together, they form the quality gates that enforce the waterfall model's sequential discipline.
Can I start the next waterfall phase before the current one is complete?
In a strict waterfall model, no — phases are sequential, and the next phase begins only after the current phase passes its gate review. Some organizations allow 'phase overlap' under formal risk acceptance, but this undermines traceability and is generally discouraged, especially in regulated environments.
How do I handle changing requirements in a waterfall model?
Use a formal change request process. Any requirement change after the Requirements phase gate must be documented, impact-analyzed, and approved before implementation. See our guide on managing change requests in waterfall projects for the full process.
What happens if a waterfall phase fails its gate review?
The phase does not advance. The team addresses the unmet exit criteria — typically through rework, additional reviews, or resolving open defects — and resubmits for gate review. The project schedule is updated to reflect the delay, and stakeholders are informed of the impact.
Is the waterfall model still relevant for modern software projects?
Yes, for projects with stable, well-understood requirements, fixed budgets, and regulatory constraints. The waterfall model excels in industries like aerospace, defense, medical devices, and large infrastructure projects where traceability, documentation, and auditability are non-negotiable.