Waterfall
Waterfall is a way of running a project in strict order: finish and sign off each phase before the next begins. Waterfall is usually taught as the outdated thing Agile replaced, which is both unfair and unhelpful. It is the right choice whenever changing your mind later costs more than specifying carefully now — and that is more often than its reputation suggests.
- First described
- Royce, 1970
- PMBOK name
- Predictive lifecycle
- Feedback point
- At acceptance
What Waterfall actually claims
Waterfall organises a project as a sequence of phases. Each one produces a document or artefact that gets signed off, and the next phase depends on it. You gather requirements, then design, then build, then test, then maintain.
The premise underneath is a specific claim about knowledge: that requirements can be known accurately in advance, and that writing them down thoroughly is cheaper than discovering them by building.
That claim is sometimes true. If you are integrating with an external system whose interface is published and fixed, or migrating data to a target you already understand, then most of the uncertainty really is resolvable on paper before anyone writes code.
The correction nobody mentions
Now for a piece of history worth knowing, because it changes how you should read every diagram of this model you will ever see.
The cascading diagram comes from a 1970 paper by Winston Royce. He drew it, and then — on the very next page — described it as an approach that "is risky and invites failure". He spent the rest of the paper explaining how to fix it: build a prototype first, involve the customer throughout, and expect to iterate.
The five phases, one at a time
Let us walk through each phase: what happens in it, what it produces, and the question that has to be answered before you are allowed to move on.
1. Requirements
Everything the system must do is gathered and written down. Not just features — also the non-functional requirements: how fast, how many users at once, what must be logged, which regulations apply.
The output is a specification, and the gate question is: do we all agree this is what is being built? The signatures here are what make everything downstream possible — and what makes a late change a contractual matter rather than a conversation.
2. Design
The specification is turned into a technical plan. This usually splits in two: high-level design decides the components and how they talk to each other, and detailed design decides what happens inside each one.
The gate question is whether this design can actually meet the specification. This is the phase where an experienced architect earns their keep, because a structural mistake found here costs a week and the same mistake found during testing costs a quarter.
3. Implementation
The code gets written, following the design. Developers write unit tests as they go, but there is no integrated system to try yet — components are built against the interfaces the design specified rather than against each other.
This is the longest phase and, counter-intuitively, the calmest. Everything has been decided; the work is execution. It is also where the project is most likely to be quietly behind, because there is no working system to measure progress against — only percentages of completion.
4. Verification
The pieces are integrated and tested together, then handed to the customer for acceptance testing. This is the first moment anyone sees the whole system behave.
And this is where the model's central weakness shows. Every assumption made in requirements — nine months ago, by people who had never used the thing — is tested at once, at the point where correcting any of them is most expensive.
5. Maintenance
The system is live. Defects are fixed, small changes are made through a formal change request process, and the product runs until it is replaced.
Worth noting: in most waterfall projects this phase is longer than all the others combined, and it is usually the one nobody plans for properly.
The V-model — Waterfall with testing planned early
There is a variant worth knowing, because it fixes the biggest practical problem with the pure model and you will meet it in regulated industries.
The V-model takes the same phases and bends the line into a V. The left arm goes down through requirements, design and detailed design. The right arm comes back up through the corresponding levels of testing. Each phase on the left is paired with the test level that will verify it.
| Left arm — building it | Right arm — verifying it |
|---|---|
| Requirements | Acceptance testing |
| High-level design | System testing |
| Detailed design | Integration testing |
| Implementation | Unit testing |
The practical gain is that the acceptance tests are written during the requirements phase, not after the build. That forces a useful question early: how would we prove this requirement is met? A requirement nobody can write a test for is a requirement nobody has understood, and the V-model surfaces those in month one rather than month nine.
The economics behind the choice
Strip away the culture war and the choice between Waterfall and Agile comes down to a single number: how much does it cost you to change your mind late?
Change is cheap → iterate
A web service with automated tests and continuous deployment. A wrong decision costs a redeploy. Deferring decisions costs almost nothing, so gather evidence instead of guessing.
Change is expensive → specify
Firmware on hardware already in customers' hands. A certified medical device. A system integration where the other side's interface is frozen by contract. Here, careful upfront thinking is the cheaper path.
Notice that this is a property of your situation, not of your beliefs about software development. The same team may be right to iterate on the web frontend and right to specify carefully on the firmware, in the same quarter.
Waterfall next to Agile
Waterfall
- Scope fixed; time and cost estimated against it
- One large feedback point, at acceptance
- Documentation is a contractual deliverable
- Strong audit trail; every gate is signed
Agile
- Time and team fixed; scope flexes
- Many small feedback points, every iteration
- Documentation written where it unblocks someone
- Audit trail must be built deliberately
How this shows up in real delivery
Very few organisations run either model in pure form. The common real shape is a predictive wrapper around iterative execution: a fixed contractual scope and milestone plan on the outside, with the team working in sprints inside it.
That hybrid is honest as long as one condition holds: the outer plan gets genuinely re-baselined when the inner work discovers something. If the plan never changes while the sprints keep finding problems, you have the appearance of iteration with none of the adaptation — and everyone can see the dates are fiction long before anyone says so.
Where it degrades
- Requirements signed off by people who will not use the system, so acceptance is the first real review.
- A verification phase compressed to fit a date, which turns testing into a formality.
- Change requests treated as failures rather than as information, so the plan is defended past its usefulness.
- Sprints inside a plan that is never re-baselined — iteration in appearance only.
- Progress reported as percentage complete, which cannot be verified until the system runs.
When to use it
Use it when
- Requirements are genuinely stable and well understood before work starts.
- Regulatory or safety certification requires an approved specification up front.
- The cost of a late change is genuinely high — shipped hardware, physical deployment, frozen interfaces.
- The contract fixes scope and price, and the client needs a date to plan around.
Avoid it when
- The product is new and its users have not yet told you what they need.
- The technology is unfamiliar, so design estimates are guesses dressed as plans.
- You can release cheaply and often — then late feedback is a cost you chose, not one you inherited.
- The plan will not be re-baselined when reality diverges, which makes the gates theatre.
Found this useful?
Share it with someone who is working on the same problem.