The Waterfall methodology is a way of running a project as a series of phases that follow one another, typically requirements, design, build, testing and deployment. Each phase is meant to be largely complete, reviewed and signed off before the next begins, so work flows downward like water over a series of steps. It puts most of the planning at the start, aiming for a predictable scope, schedule and cost, and treats later changes as exceptions to be approved and priced.
At a glance
- Projects move through sequential phases, with formal sign-off between them.
- Requirements and design are agreed in detail early, before most building begins.
- Changes after sign-off usually go through a change control process.
- It supports fixed-price, fixed-scope contracts and firm milestone dates.
- Its main risk is discovering late that what was specified isn’t what the business needs.
What problem it solves
Some projects need certainty more than flexibility. A budget may be fixed by a board or a grant. A go-live date may be set by a contract expiring, a regulatory deadline or a business event that can’t move. Several vendors, or several departments, may need to coordinate around the same dates. In those situations, buyers want to know up front what they are getting, when and for how much.
Waterfall answers that need by doing the thinking first. Detailed requirements and design documents become the basis for estimates, contracts and acceptance testing. Each phase ends with a clear deliverable, a document, a design or a tested system, that the buyer can review and approve. That makes it easier to compare bids, track progress against milestones and hold vendors to what was agreed.
How it works
Requirements. The business and the vendor document what the system must do, often in great detail, and sign the result off.
Design. Architects and designers decide how the system will meet those requirements: data, integrations, screens, infrastructure.
Build. Developers or configurators build to the design.
Testing. The system is tested against the requirements, often ending with user acceptance testing, where the buyer confirms it works as specified.
Deployment. The system goes live, followed by a support or warranty period.
Between phases, gate reviews check that work is complete before moving on. Changes after sign-off are handled through change requests: each is described, priced and approved, much like IT change management does for live systems. In practice, teams do revisit earlier phases when problems surface, but doing so is costly, which is why so much effort goes into getting early phases right.
When it matters for buyers
In the statement of work. A Waterfall statement of work (SOW) typically lists detailed deliverables, milestone dates, payment tied to milestones and acceptance criteria for each phase. Read the assumptions and exclusions carefully: they define what will trigger a change order.
Fixed scope versus time and materials. Waterfall is the usual basis for fixed-price, fixed-scope contracts, which move estimating risk to the vendor. Vendors price that risk in, and gaps in the requirements tend to come back as change orders. Time-and-materials pricing can also be used with Waterfall, but then the buyer carries more of the overrun risk without gaining Agile’s flexibility.
In large implementations. ERP and other platform rollouts often use phased or hybrid plans because of data migration, integration and cutover dates. Our ERP overview covers how implementation partners are compared.
After go-live. Shortcuts taken to hold a fixed date can leave technical debt that someone has to pay down later.
Questions to ask vendors
- Which phases will the project have, what is delivered at each, and how is each accepted?
- How detailed will the requirements be, and who on our side must review and sign them off?
- What assumptions and exclusions underlie the price, and what typically causes change orders on projects like ours?
- How are change requests estimated and approved, and what rates apply?
- How are payments tied to milestones, and what happens if a milestone slips?
- At what point will our users first see working software?
- Would a hybrid approach reduce risk for this project?
How it differs from Agile
Agile delivers software in short cycles, showing working increments to users regularly and adjusting priorities as it goes. Waterfall plans and specifies most of the work up front and delivers in sequential phases, with users often seeing the working system late, during testing. Waterfall offers more predictability on scope, price and dates when requirements are stable; Agile offers more ability to change direction when they aren’t. Commercially, Waterfall pairs naturally with fixed-price contracts and milestone payments, while Agile pairs naturally with time-and-materials or per-sprint pricing. Many projects use a hybrid of the two.