METHODOLOGY · WATERFALL

Waterfall project management, explained

One phase at a time, each signed off before the next begins. What it is, when it fits, and when to look elsewhere.

What is waterfall?

Waterfall is the classic way to run a project: you finish one phase completely, get it approved, and only then move to the next. Requirements come first, then design, build, test and release. The name comes from the picture: work flows downhill, and going back up is hard.

Five waterfall phases as a staircase: Requirements, Design, Build, Test, Release

It is still the default in places where the end result is known up front and mistakes are expensive: construction, manufacturing, regulated work and many defence and government contracts.

The five phases, in plain English

  1. Requirements: agree exactly what the project must deliver, and get it signed off.
  2. Design: decide how it will work before anyone builds anything.
  3. Build: make the thing, following the approved design.
  4. Test: check it does what the requirements said it would.
  5. Release: hand it over, go live, and close out the project.

Each phase ends with a gate: a review where someone with authority says “yes, move on.” Those gates are what makes waterfall easy to plan and easy to explain to executives.

When waterfall fits, and when to think twice

The deciding question is how much you know at the start. The clearer and more stable the requirements, the better waterfall works.

Two panels: when waterfall fits and when to think twice

Not sure? Read Waterfall vs Agile: which fits your project?

The catch: change gets expensive

In waterfall, changing a requirement on day one costs a conversation. Changing it after the build is done can mean rework, retesting and re-approval. That is why waterfall teams spend so much effort getting requirements right early.

Curve showing the cost of a change rising sharply in later waterfall phases
Illustrative shape of the idea, not measured data.

Pros and cons

Pros

  • Simple to understand and explain
  • Clear milestones and approvals
  • Easy to estimate budget and dates when scope is stable
  • Good paper trail for audits and contracts

Cons

  • Slow to react when requirements change
  • Users often see the result only at the end
  • Problems found late are costly to fix
  • Assumes you can know what you need up front

What I would actually do

Waterfall earns its place when you know what “done” looks like before you start and changing your mind later is costly. These are the situations where I would reach for it first:

  • Construction and physical build-outs: you cannot pour the foundation after the roof is on.
  • Regulated or contract-driven work: defence, government and compliance projects where scope is signed off and changes go through formal control.
  • Fixed-date deliveries with fixed scope: a product launch, an office move or a licence renewal where the date and the deliverable are not negotiable.
  • Hardware, manufacturing and installations: making changes after tooling or purchasing is expensive or impossible.
  • Migrations and rollouts with a known end state: data centre moves, system cut-overs and standard roll-outs where the steps are well understood.

A quick test: if you can write down the finished result in a page and have the key people agree to it, waterfall is a safe choice. If you cannot, look at Waterfall vs Agile before you commit.

Your next step

Compare it with the alternative, or grab the free kit with the charter and RAID log templates you will need whichever method you pick.