The Waterfall Project Phases, Step by Step

The phases are frequently listed and rarely explained in terms of what each is actually for. This guide covers what happens in each, what gets skipped, and how to make the model work better within its own assumptions.

Quick answer: Waterfall delivers a project through sequential phases — requirements, design, planning, implementation, testing, deployment and closure — with each phase completing and being approved before the next begins. The model assumes requirements can be known in advance and that change after commitment is expensive, which is true for a substantial category of work.

How Waterfall Is Structured

Waterfall organises work into phases separated by approval gates, so that each stage builds on a signed-off foundation rather than a moving one.

Sequential phases with gates

Each phase produces defined deliverables reviewed and approved before the next starts. The approval point is the stage gate.

The gate is the mechanism. Without it, phases overlap informally and the model's central benefit — building on something settled — disappears while its rigidity remains.

Why each phase completes before the next

The logic is that rework is cheapest when caught early. Design based on approved requirements is less likely to be wasted than design based on requirements still under discussion.

This holds when the requirements were correct. When they were not, the same structure means the error propagates through every subsequent phase before anyone notices — which is the model's central trade-off.

What the model assumes

Three assumptions: that requirements can be specified accurately in advance, that change after commitment is expensive, and that the outcome cannot usefully be delivered in pieces.

Where all three hold — construction, regulated manufacturing, infrastructure, compliance programmes — waterfall is efficient and appropriate. Where they do not, it is the wrong tool applied confidently.

The Phases at a Glance

# Phase Produces Typical share of timeline Gate question

Requirements

Signed-off requirement specification 10–20% Do we agree

What is a stage gate?

2

Analysis and design

design Solution design, technical specification 15–25% Will this design meet the requirement?

3

Planning and baselining

baselining Baselined schedule, budget, risk register 5–10% Is the plan realistic and approved?

4 Implementation The built solution 30–40% Is it complete against the design?

5

Testing and verification

verification Test results, defect resolution 15–25% Does it meet the requirements?

6

Deployment and handover

Documentation and handover

Live solution, trained users 5–10% Is it operating and supported?

7 Closure Acceptance, documentation,

Lessons learned

2–5% Is everything formally complete?

Phases 1 to 3: Defining the Work

The first three phases establish what will be built, how it will be built, and against what schedule and budget — and the quality of phase one determines everything after it.

Requirements Gathering, documenting and getting agreement on what the project must deliver, including functional requirements and constraints.

This phase carries disproportionate weight because every later phase inherits its errors. Time invested here is the highest-return time in a waterfall project, and cutting it short to "get started" is the most common structural mistake.

The output is a specification signed off by whoever can commit on behalf of the business — not merely circulated for comment.

Analysis and design Translating requirements into a solution: architecture, technical design, interfaces, data structures, or in physical projects the detailed drawings and specifications.

Design review is where errors are cheapest to catch after requirements. Involve the people who will build it — designs produced without input from the builders routinely contain assumptions that turn out to be expensive.

Planning and baselining Building the schedule from the design, identifying dependencies and the critical path, allocating resources, establishing the budget and the risk register.

Baselining is the important act. Saving the approved plan means later variance is measurable, and without it the schedule silently rewrites itself as dates move.

Phases 4 to 6: Building and Verifying

Implementation produces the solution, testing verifies it against the requirement, and deployment moves it into operation with the people who will run it.

Implementation

The longest phase, where the design is built. The project manager's work here is largely progress tracking against baseline, managing change requests, and removing blockers.

The risk in a long implementation phase is that nobody sees a working result for months.

Building interim review points — a demonstration of partial functionality, a site inspection — is the single most effective mitigation available.

Testing and verification Verifying the built solution against the design and the original requirements: system testing, integration testing, user acceptance testing.

Defects found here are expensive precisely because they may trace back to a requirements error made months earlier. Compressing testing when the schedule is tight is common and consistently a false economy — it moves the defects into production rather than removing them.

Deployment and handover Releasing into operation, migrating data, training users, and transferring support responsibility.

Handover is frequently underestimated. The operational team inheriting the solution needs documentation, training and a support model, and none of it exists unless the plan allocated time for it.

Phase 7: Closure and What Teams Skip

Closure covers formal acceptance, final documentation and lessons learned — and it is routinely rushed because the team has already moved on.

Formal acceptance

The sponsor formally accepts that the deliverables meet the agreed criteria.

This matters commercially and organisationally. Without formal acceptance, projects drift into an indefinite state where minor requests continue arriving and nobody can say the project is finished.

Documentation and handover

Final as-built documentation, operating procedures, support arrangements and any contractual closure.

Documentation written at closure is always worse than documentation maintained throughout.

Where it can be produced as a by-product of the work — specifications and decisions recorded against the tasks that produced them, as a linked document rather than a separate deliverable — closure becomes assembly rather than authorship.

Lessons learned A structured review of what worked, what did not, and what the organisation should do differently next time.

This is the phase most often skipped, and skipping it is why the same problems recur across projects. It takes an afternoon and is the only mechanism by which an organisation's project maturity improves.

Making Waterfall Work Better

Within the model's own assumptions, three practices improve outcomes: front-loading unknowns, building review points into long phases, and treating change control as a service.

Front-load the risky unknowns

If something is uncertain — a technical approach, a supplier capability, a regulatory interpretation — resolve it early, even if the phase sequence would naturally address it later.

A prototype, a trial, a supplier assessment during requirements or design costs little and prevents discovering the problem during implementation, when the plan is committed.

Build review points inside long phases

A six-month implementation phase with no interim demonstration is six months of unverified progress.

Insert checkpoints where something partial is shown or inspected. This borrows agile's feedback principle without changing the model's structure, and it is the cheapest available protection against a late surprise.

Treat change control as a service, not a barrier

Change control exists to make the consequences of a change visible, not to prevent change.

When it operates as an obstacle course, people route around it with informal agreements, and the project ends up with undocumented scope. Make it fast and make the answer useful — here is the cost and the schedule impact — and it will be used properly.