Please Share

What Really is the Waterfall Method?

What is the Waterfall Method

Waterfall is a term we hear a lot in Project Management. But there are still too many project managers who don’t know what it really means.

Like many other Project management sites, we did a comprehensive article comparing Agile vs Waterfall Project Management. But I have had many people who want to know more about what Waterfall is… on its own merits!

So, here’s what we will cover…

What is the Waterfall Method
  1. The Essence of Waterfall Project Management
  2. Historical Perspective on the Waterfall Method
  3. The Stages of The Waterfall Method
  4. When to Use the Waterfall Method
  5. The Essence of Good Waterfall…
    How to Do Waterfall Project Management Well

…and Here’s What We Won’t Cover

And we won’t cover it, because you can already find it in our article: ‘Agile vs Waterfall: Which one is Right for Your Project?’ We won’t cover:

  1. What are Agile and Waterfall?
  2. The Principal Differences between Agile and Waterfall
  3. When to use each One
  4. Agile-Waterfall Hybrids
  5. The Impact of Domain on your Choice of Agile or Waterfall

The Essence of Waterfall Project Management

Here is something that is probably true… If u cannot explain something to a 7 year-old, then you don’t fully understand it.


The essence of the waterfall method is a way to get big, complicated things done, step by step. Click To Tweet

Let’s Break it Down

First, the Waterfall Method is a Project Management approach. It’s a way to tackle a load of interdependent tasks and activities. It works towards a defined end-point.

Second, it does this in a sequential way: one step at a time. And it continues until it reaches that end-point.

This means a whole lot of other things, like definition, design, planning, and testing. These are the characteristics of waterfall project management, and we’ll look at them later. But they aren’t its essence.

A Summary of This Article

If you are a watcher, rather than a reader, we have produced a video summary of this article:

Historical Perspective on the Waterfall Method

I don’t want to bore you with detailed history. But nay serious project manager should understand this simple 3-step account of how perceptions of the waterfall method have evolved.

1. Software Engineering Phases

The Waterfall method started life as a description of software engineering phases in the construction of a Cold War era computer network by Herbert D Benington in 1956.

Winston Royce

In 1970, Winston S Royce wrote a paper developing the idea, and citing a 6-phase approach that was to become the basis of modern interpretations of the Waterfall method:

  1. Product requirements
    1. System Requirements
    2. Software Requirements
  2. Analysis
  3. Design
  4. Coding
  5. Testing
  6. Operations (installation, support, and maintenance)

In fact, even then, Royce recommended we take an iterative approach to software development. He advocated that projects should pass through his stages at least two times. As a ‘single-pass’ approach, it was flawed.

Although Royce did not use the term ‘Waterfall’, a common diagrammatic representation of his 6 stages shows where the metaphor comes from.

Waterfall Project Management - Winston Royce Stages

Bell & Thayer: ‘Waterfall’

However, neither Benington nor Royce had used the term ‘Waterfall’. It seems (Wikipedia) that the first to do this were T E Bell and T A Thayer in  Software requirements: Are they really a problem? (1976).

Adoption by the US DoD

The United States Department of Defense adopted this approach in 1985. They set out standards for their contractors. In 1985, the standard mandated contractors working in software development to use a software development cycle…

that includes the following six phases:

1. Software Requirement Analysis
2. Preliminary Design
3. Detailed Design
4. Coding and Unit Testing
5. Integration
6. Testing

United States Department of Defense standard: DOD-STD-2167A
Waterfall Project Management - US DoD Stages

2. Not Suitable for Software Engineering?

Back in 1970, Royce had already advocated for an iterative, rather than strictly linear, approach. He also discussed the importance of prototypes.

As software and our understanding of the challenges in developing it efficiently have evolved, Royce’s critiques have gained salience. There are plenty of good reasons to recognize that the waterfall approach is not well suited to much of modern software development.

Modified Waterfall Approaches

To fix its shortcomings, there are no end of modified and hybrid approaches, like:

  • Waterfall with Sub-projects
    We discuss this in our article on Agile vs Waterfall.
  • Waterfall with Risk Reduction
    Effectively creating a Minimum Viable Product (MVP) at the start of the sequence of stages, to reduce risk.
  • Sashimi
    Overlaps the stages to create short feedback cycles before fully committing to the subsequent phase.

But Well-suited to Plenty Else!

Project Managers often go through a lot of loops (pun intended) to make Waterfall work well for software projects. But the fact is that nowadays, we recognize that it’s usually not the right approach.

But that does not mean that it is a poor method. For many projects (and we’ll look at the strengths of the method later), it is very well-suited. For example:

  • Compliance and regulatory projects
  • Cut-over projects
  • Construction projects
  • Manufacturing projects
    But many new product development (NPD) projects now use a more iterative Agile approach
  • Organizational Process Change projects
    But, increasingly, process improvement and organizational change projects are using a more iterative Agile approach

The OnlinePMCourses Core Programs

As a result, our Core Project Management programs focus on the waterfall approach.

3. Modern Polarity: Agile vs Waterfall

This brings us to the present day.

There has been a polarization over the last 10 to 20 years. Many Agile practitioners have labeled Waterfall in contrast to Agile, as in some way ‘bad’. And therefore, they brand many of the practices that make good waterfall project management (we’ll see them later) as being equally bad – like estimating budgets and durations.

This is, frankly, bonkers!

I will have nothing to do with it. Sensible Project Mangers have nothing to do with it. And you should have nothing to do with it. Both Agile and Waterfall Project Management have their strengths and weaknesses in any given domain and for any specific use. Your job is to select the right approach for each project.

Once more…
Do look at our article, Agile vs Waterfall: Which one is Right for Your Project?

Better Language

one result of this antipathy from some in the Agile community has been the use of the word Waterfall as a pejorative term.

So, I prefer a more descriptive and helpful label… either

  • Planned Project Management or, better,
  • Predictive Project Management

The Major Methodologies

While all the major Project Management organizations are running hard to integrate Agile and Waterfall into their documentation, all retain strong bases of knowledge around a predictive project management approach:

  • The PMI documents a fundamentally Waterfall method in its Project Management Body of Knowledge (PMBOK Guide) 6th Edition. We need to wait to see how the 7th Edition will handle things.
  • While the APM‘s Body of Knowledge (APM BoK) 7th edition is largely agnostic on approach, there is a clear bias towards predictive project management.
  • The IAPM has paired guides:
    Its PM Guide 2.0 is based on traditional predictive project management, while he Agile PM Guide 2.0 is based on…well, you can guess!
  • The IPM bases its certifications largely on a predictive approach.
  • There is a PRINCE2 Agile solution and set of qualifications in the Axelos Best Practice portfolio. But PRINCE2 itself is far more widely known and is based on a waterfall paradigm.

The OnlinePMCourses Core Programs

Our Core Project Management programs also focus on Predictive Project Management.

The Stages of The Waterfall Method

As you would expect, there is no single, definitive, articulation of the stages of a waterfall project. We’ve already seen, above, those articulated by Royce in 1970 and the US DoD in 1985.

Here is my preferred articulation of the original Waterfall paradigm.

  1. Requirements
  2. Design
  3. Implementation
    Royce called this ‘coding
  4. Testing
    Sometimes called ‘verification
  5. Installation
    Delivery and deployment of the products
  6. Maintenance
    Ongoing operational use and support – sometimes referred to as ‘production’ in the IT sector
Waterfall Project Management - Basic Approach

And, because I teach predictive project management in our Core Project Management program, here are the four lifecycle stages that I use in that, rendered into the ‘waterfall metaphor’.

  1. Definition
    Includes requirements-gathering
  2. Planning
    Includes design of products/deliverables
  3. Delivery
    Also called implementation. I include testing as a part of this stage
  4. Closure
    Handover, which marks the transition from the Delivery to the Closure stage, is akin to installation. I see maintenance as outside of the project.
Waterfall Project Management - OnlinePMCourses Lifecycle Stages

When to Use the Waterfall Method

The best way to answer the question: ‘when should I use the Waterfall method?’ is with an assessment of its:

  • Characteristics
  • Myths
  • Strengths
  • Weaknesses

Characteristics of Waterfall Project Management

The strengths and weaknesses of Waterfall Project management will flow from its primary characteristics:

  • Robust definition of the end product
    You know what you are creating and have precise measures of success
  • Careful planning and budgeting
    Sponsors and clients don’t just know what they will get. They also know when they will get it and how much it will cost them. This makes for better decision-making (governance).
  • High levels of project governance
    Embedded in the Waterfall approach, this leads to high levels of rigor, arising from significant use of documentation during and resulting from the project

Myths of Waterfall Project Management

Accusations are often made by detractors of the approach, which are simply not true of predictive project management in skilled hands. Some of the weaknesses (or ‘cons’) of waterfall project management that you will find on other sites are simply wrong. They are based on myths like:

  • Low engagement with customers and stakeholders
    In fact, all good project management (agile and predictive) engages actively with all stakeholders
  • An ‘all at once, big bang approach to delivery’
    Some projects have to be this way – half a bridge is not much use). But in others, incremental approaches are possible. In these cases, it may be that some badly-designed projects plan for a big-bang delivery, but the good ones don’t. Predictive projects can absolutely deliver incrementally.
  • Allows for no refinement of or change to the scope or specifications
    I call BS on this! Take a look at our article on Project Change Control!

Strengths of Waterfall Project Management

  1. Rigor and Reliability
    The simplicity and structure of a linear model make waterfall easy to apply and do well. This makes it possible to focus on each step and ensure that you complete it properly before moving on.
  2. Stage Gates
    Following on, these allow for the implementation of a stage-gate process.
  3. Good Governance
    The structure also encourages and simplifies the imposition of a robust governance régime. This focus on governance suits the approach well to highly accountable domains like the public and charitable sectors.
  4. Knowledge Management and Auditability
    The high levels of documentation that a predictive project can generate make it easier for an organization to capture and retain knowledge. This is good for both learning and creating an audit trail.
  5. Stakeholder Expectations
    The planning and documentation support the essential process of managing stakeholder (and client and user) expectations.
  6. When and How Much
    From the early stages, stakeholders, clients, and sponsors also know when to expect delivery and how much the finished products will cost.
  7. You know when you have Succeeded… or Failed!
    With a clear definition of the end-point and objectives, you have a solid basis to evaluate success… and failure.
  8. Better by Design
    While agile process allow designs to evolve as people clarify their needs and expectations, they can leave legacy components that are not needed and create maintenance issues. Planned projects create a coherent design at the outset, and then manages changes with a rigorous process.
  9. Predicting Problems
    No project will ever be without risk. But a rugged design phase can iron out many potential problems and prevent much abortive work.
  10. Team Deployment
    With good planning comes the ability to deploy team members efficiently. And, from their point of view, this allows them to plan and manage their own time efficiently.

So, the Waterfall Method is Ideal when:

  • Requirements are understood clearly
  • You have fixed budgets, timescales, or requirements
  • Accurate estimates are possible
  • Partial solutions are useless (or inefficient)
  • There is a fixed deadline
  • The technology you are using is unlikely to evolve

Weaknesses of Waterfall Project Management

Waterfall Project Management does have its shortcomings, however:

  1. Slower Delivery
    If you need something usable, fast, then Waterfall is not for you.
  2. Needs Clarity about Required Outcomes Early on
    This means that, if your client or users do not know clearly what they want, the approach will either get stuck or need to make assumptions. In the latter case, fixing incorrect assumptions can be costly and time-consuming.
  3. Imperfect Foresight
    The strength of being able to foresee issues and plan for them is countered by the reality that we cannot always foresee problems accurately. You may build plans on mistaken solutions and assumptions, leading to a need for re-work.
  4. Dependencies
    The nature of the linear process means that errors or delays in one set of activities can have knock-on implications for some or all subsequent work.
  5. All-at-once Testing
    Having testing as a stage can mean that errors are discovered later in the project. This can mean that remediation is more costly and more time-consuming than necessary.
  6. Evolving Requirements
    Where client, user, or other stakeholder requirements evolve substantially, a structured change control process can be cumbersome and costly.

So, Waterfall Project Management is Not Ideal when:

  • Stakeholders are not clear on the details of their requirements
  • …or on their the priorities of different functionality
  • You need something quickly, and are prepared to upgrade or update it later
  • Technical capabilities, requirements, or standards are evolving rapidly
  • You need users to evaluate the product before you can finalize it

The Essence of Good Waterfall…
How to Do Waterfall Project Management Well

The whole of our core Project Management programs and many of our articles and Youtube videos are about this topic. So, I shall not go into details here. But, the headlines are:

  • Use it when it’s the right method
    Waterfall, or Predictive, Project management is a well-developed and robust approach to project delivery. But it may not always the best one for your situation. So, select carefully. Never criticize a hammer for being unable to remove a screw.
  • Good Governance
    The quality of your project management will always be directly related to the quality of your governance:
    • Processes
    • inputs
    • Documentation
    • People
  • Choose the right lifecycle stages
    The Waterfall metaphor refers to a series of stages. But it is up to you, as Project Manager, to determine what the right stages are to give you optimum control, accountability, and effectiveness.
  • Clear Goal, Objectives, and completion criteria
    The need to determine your end-point at an early stage of the predictive project process means also being clear on your goal, objectives, and completion criteria.
  • Realistic Estimating – time and budget
    If the waterfall method needs plans and budget, it also needs realistic estimates. So you need to get skilled at the craft of creating estimates.
  • Understand the risks
    Shift happens! And things go wrong. So you also need to understand and practice effective risk management.
  • Active, respectful stakeholder engagement
    For me, good stakeholder engagement is even more important than risk management.
  • Robust Change Control Process
    There’s a criticism that waterfall project management cannot handle change. That’s nonsense, of course. But you do need to be able to build a robust change control process.
  • Comprehensive Project Documentation
    Good governance means transparency, good reporting, record-keeping, and decision-making. You need the right documentation deliverables, and good documentation management, too. Here’s how to get it right.

What are Your Thoughts, Experiences, and Questions about the Waterfall Method?

Do let me know. As always, I’ll respond to any comments, below.

About the Author Mike Clayton

Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.

follow me on: