Under waterfall methodology, each phase finishes and gets formal sign-off before the next one starts. Scope, schedule and cost are fixed early, in documented requirements.
Construction and defense contractors use it, and software teams do too whenever requirements are stable and late change gets expensive. Agile and iterative approaches are what people usually compare it against.
The origin story most people repeat is off. Winston Royce’s 1970 WESCON paper, the one usually credited with the model, never uses the word waterfall. It actually calls a single-pass sequential build risky and prone to failure.
What is waterfall methodology?
People also call it the linear-sequential model or the classic lifecycle model. In PMI vocabulary it’s a predictive life cycle. As a project management and software development approach, it moves in one direction, with no planned return to an earlier phase, and everything gets pinned down early in the documented requirements.
It helps to rule out a few things. It isn’t iterative or incremental. A return to design happens through a formal change request, not a planned loop, and the customer gets the whole system at the end instead of slices along the way. Nor is it adaptive: requirements are an input to the plan, and the plan doesn’t keep revising them.
Iterative approaches to building software rework a slice of the product several times. Here the whole product gets built once and tested afterwards.
It’s among the oldest lifecycle models for software, and it’s still used in construction and in aerospace and defense programs, where a late change means physical rework.
Treat “waterfall” as a reference model. Real projects bend it.
The phases of waterfall methodology and what each one hands off
Each phase ends by handing a signed deliverable to the next one. The usual sequence is requirements, design, implementation, verification and maintenance.
Requirements start with a feasibility study and end with a software requirements specification that stakeholders approve. Design produces the architecture and detailed design documents the build team codes against. Implementation is source code written to that approved design, with unit-level checks along the way. Verification measures test results against the specification and finishes with customer acceptance testing. After delivery, maintenance covers defect fixes and releases handled against the delivered baseline.
Phase counts differ by source. Royce’s 1970 paper pictured seven steps: system requirements, software requirements, analysis, program design, coding, testing and operations. Lucid counts six phases and Lightcast’s skills taxonomy lists eight. Names change from source to source, but the order stays the same.
The requirements deliverable carries the most weight, because every later phase is checked against it. Teams that format it to a standard now look to ISO/IEC/IEEE 29148, which replaced IEEE 830-1998 in 2011 according to IEEE’s own record. A 2018 edition has since taken over.
A software requirements specification written to that standard defines what a good requirement looks like, which is the part most teams skip.
In the design phase the team writes the design document that implementation then follows.
Testing starts only after implementation finishes. A flawed requirement therefore surfaces in verification, when fixing it means reopening the design and the code and then testing again.
How phase gates and change control work
At a phase gate, named approvers review whether the phase met its exit criteria. Only a passed gate releases the next phase.
Gate criteria
NASA closes every project phase with a key decision point backed by major reviews, according to a 2011 systems engineering briefing from NASA’s Marshall Space Flight Center. PRINCE2 has the Project Board authorize one management stage at a time, working from an End Stage Report. On a typical software project the gates look for a signed requirements specification, an approved design review and passed acceptance tests.
The watchdog’s 2019 report on NASA’s major projects, GAO-19-262SP, names the technical reviews that feed those decisions. They are the system requirements or mission definition review, the preliminary design review (PDR), the critical design review (CDR) and the system integration review (SIR).
The outcome is rarely a flat yes or no. A PRINCE2 board reviewing an End Stage Report can approve, ask for a revision, amend the scope or stop the project.
Gates catch missing deliverables more reliably than wrong ones. A signed requirements document can still describe the wrong product.
Change requests after baseline
Sign-off turns the approved documents into a baseline. From then on, a change is a formal request, not an edit.
- Log the request with its reason and requester
- Assess the impact on cost, schedule and every signed document it touches
- A change control board approves, defers or rejects it
- If it’s approved, update the baseline and reissue the affected documents
Handling these requests consistently takes a disciplined change request process, and the board’s decision is only as good as the impact assessment in front of it.
The baseline itself sits under software configuration management, so the team always knows which version of the requirements the current build answers to.
Tight control keeps scope stable, though it also makes every legitimate late change slow and expensive. Honestly, that’s the price of the whole approach.
How to plan and run a waterfall project
Planning goes in a fixed order. The scope gets broken into a work breakdown structure, the tasks get sequenced, the critical path gets found, a baseline gets frozen, and variance is then tracked against it on a Gantt chart.
| Artifact | What it answers | Where it breaks |
|---|---|---|
| Work breakdown structure | Which deliverables make up the scope | Built by phase instead of by product |
| Critical path method | Which tasks set the finish date | Estimates or dependencies are wrong |
| Baseline | What was approved | Changes bypass the change board |
| Gantt chart | Who does what, and when | Shows the plan, not whether the requirements are right |
For software work, a written software development plan pulls the WBS, schedule, roles and milestones into one approved document.
NASA’s WBS handbook (NASA/SP-2010-3404, January 2010) describes the structure as a way to split total scope into manageable units and a basis for schedule development. The same handbook shows a phase-oriented WBS as an unsuitable structure.
A WBS laid out as Requirements, Design, Build and Test is exactly that structure. Organize by deliverable, then schedule the phases across them.
Frameworks add the governance. The PMBOK Guide from the Project Management Institute treats this style of work as a predictive life cycle, while PRINCE2 splits a project into management stages with a board decision at each boundary.
Which project management framework a team picks decides who signs at each gate and which reports travel with the request.
Tooling is where it gets fiddly. Microsoft’s retirement date for Project Online was September 30, 2026, per message center notice MC1478955, and Project desktop and Project Server weren’t affected by that retirement, according to the same notice. For Planner premium, Planner Plan 1 adds the Timeline (Gantt) view and task dependencies, while baselines and critical path start with Planner and Project Plan 3. Plan 5 includes them too, but Microsoft moved it to end of sale on May 1, 2026.
A tool does not rescue a plan built on unvalidated requirements. The critical path is only as reliable as the task estimates behind it.
When does waterfall methodology fit a project?
It fits when requirements can be signed before design starts and late change is costly or audited. It’s an easier call still when users can’t react to partial output anyway.
A quick way to decide is to count the yes answers to these questions.
- Requirements are stable enough to approve before design begins
- The technology is known, so nobody needs a spike to learn whether it works
- A late change means physical rework or repeated certification
- Scope and price sit in a signed contract
- Users cannot judge anything until the finished system exists
As a rough rule, four or five yes answers make a sequential plan the sound default. Two or fewer point toward iteration, or a hybrid with gates only around the fixed parts. Three is a judgment call.
Construction is the clean case, because a foundation has to exist before framing starts. Aerospace and defense programs fit for a similar reason: hardware dependencies fix the order of work.
Regulated work gets over-credited. FDA’s 1997 design control guidance illustrates design controls on a waterfall process, but the same guidance says the design control process is revisited many times during a product’s life. That is not a single pass.
The rulebook has also moved. FDA’s Quality Management System Regulation took effect on February 2, 2026 and points device makers to ISO 13485:2016 for design and development.
The software standard is just as neutral. ISO/IEC/IEEE 12207:2026, published April 29, 2026, does not require any specific life cycle model.
What regulators ask for is a traceable record of inputs, reviews, verification and validation. Sequential phases produce that record almost by default, so waterfall gets mistaken for the requirement.
When compliance obligations on a software product demand traceability, a sequential plan meets them with less effort. That’s a reason to choose it, not a mandate.
On the plus side, fixed scope makes cost and schedule easy to forecast, and every phase leaves a signed document trail. Explicit handoffs let new people join mid-project, and the model fits fixed-price contracts. The downsides are less pleasant. Specialists wait idle between handoffs, early estimates become commitments when uncertainty is highest, and value arrives once, at the end.
The paper trail is the real asset. Maintenance teams inherit complete technical documentation the phases leave behind instead of tribal knowledge.
How does waterfall methodology compare with agile, the V-model and the spiral model?
Waterfall plans first and tests last. Agile works in short cycles instead. The V-model keeps the sequence but pairs each phase with a test level, and the spiral model chooses its next cycle by risk.
| Model | Feedback arrives | Change handling | Best fit |
|---|---|---|---|
| Waterfall | At acceptance, after build | Formal request after baseline | Stable scope, fixed contract |
| V-model | At each paired test level | Formal, matching test plan changes too | Verification-heavy systems |
| Spiral | At each risk review | Absorbed into the next cycle | Large projects with open risks |
| Agile | Every iteration | Backlog reprioritized | Evolving needs, reachable users |
The Agile Manifesto came out of a February 2001 meeting of 17 practitioners at Snowbird, Utah. Most agile versus waterfall debates trace back to one of its four values, “responding to change over following a plan.”
The V-model pairs each development phase with a test level, from unit tests up to acceptance, and sources date it differently. A German-language survey credits Boehm in 1979, while a 2024 arXiv paper describes parallel invention in Germany and the United States in the late 1980s.
Boehm described the spiral model in 1986 and reached a wider audience through IEEE Computer in 1988. Each cycle targets the largest open risk, and Boehm later framed waterfall, incremental and prototyping approaches as special cases that fit particular risk patterns.
A hybrid, or modified waterfall, keeps the gates and iterates inside a phase. It fails when change control stays at gate level, because work done iteratively has no approved route into the baseline.
Why do waterfall projects fail, and when does the model not apply?
Projects fail when requirements keep moving after sign-off. They also fail when delivery takes longer than the technology stays current, and when gates certify documents instead of working software.
The numbers tell part of that story. Across 32 major DoD automated information systems, the average time to deliver an initial capability was 91 months, from an ASD(NII) analysis that the Defense Science Board’s 2009 IT task force cited and that a Naval Postgraduate School acquisition research paper (NPS-AM-10-038) repeats. The FBI had spent $170 million on its Virtual Case File when the Justice Department’s inspector general judged it a failure and the Bureau abandoned it in April 2005.
On the agile side, the Standish Group’s 2011 CHAOS report assigned agile a 3x success-rate advantage over waterfall. Eveleens and Verhoef tested Standish’s success definitions against a real-world sample of 1,211 projects (IEEE Software, 2010). Separately, Menzies and colleagues found no consistent late-fix penalty in a sample of 171 projects (Empirical Software Engineering, 2017).
Failure modes
The National Academies’ 2010 review of defense IT acquisition read the long wait for a first usable capability as a mismatch with the pace of commercial technology. The Virtual Case File had a different problem. It had no defined requirements when its contract was signed in 2001, per the Centre for Public Impact’s case study. Then there are gates that certify paper, where sign-off confirms a deliverable exists and matches the document before it.
That last one depends on how gates are written. Vague acceptance criteria let a deliverable pass without proving the system works.
Late defects raise a separate question. Does fixing them later cost more? The textbook rule says yes, and it’s the usual argument against testing after build.
Menzies, Nichols, Shull and Layman tested that rule and found no consistent or substantial late-fix penalty. They suggest the effect may be a relic that appears only in certain kinds of projects.
Teams can check their own case by pulling hours-to-fix from testing lifecycle data, grouped by the phase where each defect was introduced.
The Standish Group evidence
The 2011 CHAOS report counted a project as successful only if it finished on time, on budget and with every planned feature. It covered projects run from 2002 through 2010, and Mountain Goat Software notes that it does not say how many projects sit behind the result.
Standish reports that agile projects succeed far more often than waterfall ones. Eveleens and Verhoef pushed back. They applied Standish’s definitions to their own project data and called them misleading, because success is judged only by estimate accuracy, and the Standish figures did not reflect the cases they studied.
The two sides are measuring different things. Standish looks at whether a project hit its original estimate. Eveleens and Verhoef care more about whether that estimate was any good in the first place.
Treat any single agile-versus-waterfall success percentage as an indication, not a verdict.
Cases where waterfall methodology does not apply
Waterfall doesn’t apply when requirements depend on how users react to working software, or when the technology is new enough that a prototype has to answer feasibility questions first. It also fails to fit if the customer needs a first release long before the full scope is known, or if stakeholders can’t commit to a signed specification.
For an uncertain project, a short prototype before sign-off is a cheaper fix than a thicker specification.
Who invented waterfall methodology, and did Winston Royce recommend it?
No single person invented it. Herbert Benington described a phased, top-down approach for the SAGE air-defense software in 1956. Royce criticized a single-pass version in 1970, and DoD-STD-2167 added contractual documentation requirements in 1985.
Benington and SAGE (1956)
Benington presented “Production of Large Computer Programs” at a June 1956 symposium in Washington, D.C., drawing on the SAGE program.
Boehm’s 1988 spiral model paper in IEEE Computer traces the stagewise model to that same SAGE experience.
The author was less sure of the idea later. In his 1983 foreword to the reprint (Annals of the History of Computing, vol. 5, no. 4), Benington named an oversized leap in program size as the biggest mistake on the project.
Royce’s 1970 paper
“Managing the Development of Large Software Systems” appeared in the August 1970 IEEE WESCON proceedings (pages 1 to 9), and it does not use the word waterfall.
Royce laid out the sequential flow and then called the single-pass version risky and likely to fail. His fixes start with program design first, meaning a preliminary design before analysis begins, and heavy documentation of that design. He also wanted it done twice, with a first version built to learn from so the delivered one is effectively the second. Testing has to be planned, controlled and monitored, and the customer should be involved, with a commitment secured before final delivery.
The “do it twice” step is prototyping in modern terms, done before the committed build.
His own figures show arrows back to the preceding phase. Read whole, the paper argues for sequential phases plus feedback, closer to a hybrid than to the version most critics attack.
How defense standards locked the model in
DOD-STD-2167 was published on June 4, 1985, listing the documents a contractor delivers under a phased development cycle. DOD-STD-2167A updated it on February 29, 1988, and MIL-STD-498 replaced 2167A in December 1994, merging earlier standards.
Section 4.1.2 of DOD-STD-2167 says more than one iteration of the development cycle may run at once, and calls the approach evolutionary or incremental. Larman and Basili’s 2003 history in IEEE Computer reads it differently. They describe the model DoD-Std-2167 required as a “strict, document-driven, single-pass waterfall model.” They add that DoD overseers and contractors often viewed 2167A as the epitome of waterfall, even though its authors meant it to stay neutral on life-cycle method.
The disagreement sits between the standard’s wording and how contracts applied it. On Larman and Basili’s reading, the waterfall most people criticize owes more to how defense standards were written and used than to Royce’s paper.
Waterfall Methodology FAQ
Is waterfall methodology still used today?
Yes, mainly where scope is fixed and rework is costly: construction, aerospace, defense and regulated product development. Teams that need contractual certainty often keep signed requirements and phase gates inside a hybrid setup instead of running a pure single pass.
Is waterfall the same as the software development life cycle?
No. The software development life cycle is the general sequence of stages any software goes through, and waterfall is one model of that cycle, run strictly in order with sign-off between stages.
Agile and spiral teams pass through the same stages in different patterns.
What does a waterfall project manager do?
The project manager builds the plan and holds the baseline, then runs the gates. That covers the work breakdown structure and schedule, variance tracking, change requests for the change control board, and collecting sign-off at every phase boundary.
What does a waterfall project look like in practice?
Picture a fixed-price contract to build a hospital billing module. The team signs a requirements specification and designs against it, then codes the approved design. Testing happens once the build is complete, and the system goes over for acceptance, with users seeing it only at that last stage.
Testing Requirement Stability Before You Lock the Baseline
Waterfall methodology works only on requirements that stakeholders will sign, so stability gets tested before the baseline is locked, not assumed.
Start by putting every requirement in front of its approver. Then prototype the riskiest one, and baseline only what survives both. Approval costs a meeting and a prototype costs build time, so the cheaper test goes first.
Any requirement an approver will not sign is not ready. It leaves the baseline and moves to a later iteration, which makes the plan a hybrid on purpose instead of by accident.
The cost is a slower start. In return, the team gets a documented basis for later change decisions, and requirements engineering supplies the elicitation and validation techniques that make the check reliable.
- MongoDB Cheat Sheet - October 20, 2026
- Adding AI Video Generation to a Software Product: Architecture, Cost Guardrails and QA - October 20, 2026
- Show Hidden Characters, Spaces, and Line Endings in Notepad++ - October 19, 2026
