Waterfall

Waterfall is software's classical method: define everything up front, build it in sequence, test at the end. The industry has spent two decades migrating away from it — yet it persists wherever requirements are genuinely stable and the cost of late change is genuinely intolerable. Knowing when waterfall is actually the right answer, rather than a dated one, is an underappreciated executive skill.

What It Is

Waterfall executes the SDLC as a strict sequence — requirements, design, implementation, testing (verification), deployment, maintenance — with each phase completed and signed off before the next begins. Its logic: decisions made once, early, when they are cheapest; changes after sign-off handled through formal change control. Its documented weakness, recognised since the 1970s: real projects discover their true requirements late, and waterfall's structure prices that discovery at its most expensive point — after the system is built. Fixed-price government contracting, safety-critical systems with certifiable phases, and hardware-coupled development remain its strongholds.

Why It Matters to You

Waterfall's relevance to you is comparative. Its commercial shape — fixed scope, fixed price, phase-gated payments — maps onto vendor contracts cleanly, which is why procurement teams still default to it and why 'agile vs waterfall' is really a question about contract structure and risk allocation. The honest modern position is neither purist: most large engagements are hybrid — discovery phases run iteratively, then delivery contracts with defined milestones. The failure pattern to guard against is waterfall where requirements are unstable: every change request becomes a renegotiation, and the project spends its life amending the thing it froze too early.

When You'll Meet It

In procurement models, government tenders, and any debate about delivery approach. When someone proposes waterfall, test the premise: how stable are the requirements, really, and who pays when they change?