Waterfall software delivery: what it is, where it fits and where it struggles

Waterfall plans work as a sequence of stages

Waterfall is a delivery approach in which work moves through defined stages, commonly requirements, design, implementation, testing, release and maintenance. Each stage produces information or an artefact intended to support the next one.

Its central idea is not simply “plan first”. It is that important decisions are made and reviewed at agreed points, so a team can establish what is being delivered before committing to detailed construction. A project may use documents, sign-off gates, test evidence and change-control procedures to make those decisions visible.

The model is often described as strictly one-way. Real delivery is rarely that neat: testing reveals gaps, technical investigation changes a design and users clarify what they need. The useful question is how costly and controlled that return journey is.

The stages can create clarity and accountability

For a well-understood problem, a sequential approach can make responsibility clear. Requirements explain the intended outcome, design explains the chosen approach, implementation creates it and testing provides evidence that it behaves as agreed.

This is valuable where a change needs formal approval, an external supplier needs a stable contract or a safety, legal or audit obligation requires traceability. A team can show which decision led to which design and which test demonstrates the result.

Waterfall is most credible when the key assumptions are genuinely stable. The fact that a plan is detailed does not make the underlying problem understood.

Late feedback is the fundamental risk

If a team discovers in testing that users need a different workflow, that change may affect requirements, design and implementation already treated as complete. The cost rises because several downstream decisions now need revisiting.

This is especially difficult for new products, complex user journeys and integrations whose behaviour cannot be known fully from documents. Building a complete solution before showing it to real users can produce a technically correct answer to the wrong question.

A long phase does not guarantee better thinking. Early prototypes, technical spikes, service walkthroughs and small integration tests can turn assumptions into evidence before a large commitment is made.

Waterfall and Agile address uncertainty differently

Agile delivery usually seeks shorter feedback loops: small increments, regular review and the ability to reorder work as the team learns. That does not mean no planning, no documentation or no controls. It means that planning is revisited as evidence changes.

Waterfall emphasises up-front definition and controlled hand-offs; Agile emphasises collaboration and adaptation while delivering usable increments. A mature team can borrow practices from both: clear decision records and release evidence alongside prototypes, demos and iterative delivery.

The distinction should not become a ritual choice. Choose the amount of up-front definition and the frequency of feedback according to risk, uncertainty, contractual obligations and the cost of changing direction.

Use stage gates as questions, not theatre

A stage gate is useful when it asks a consequential question: are the rules understood enough to proceed, have the important risks been tested, is the design operable, and is there evidence that the release is safe? It is not useful when it merely confirms that a document exists.

Keep the evidence proportionate. A small low-risk change may need a concise description, peer review and automated checks. A regulated or high-impact change may need traceability, security review, operational rehearsal and explicit approval.

If new evidence challenges a prior decision, make the change visible and reassess it. Pretending that a signed-off requirement cannot change creates hidden workarounds rather than control.

• Use sequential stages when the outcome and constraints are stable enough to support them
• Make each gate answer a real delivery or risk question
• Seek user and technical feedback before expensive commitments
• Treat formal documentation as evidence for decisions, not an end in itself
• Expect and manage change when new information arrives
• Match controls and traceability to the consequence of getting the change wrong