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!
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.
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:
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.
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
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:
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.
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.
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.
Implementation Royce called this ‘coding‘
Testing Sometimes called ‘verification‘
Installation Delivery and deployment of the products
Maintenance Ongoing operational use and support – sometimes referred to as ‘production’ in the IT sector
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’.
Definition Includes requirements-gathering
Planning Includes design of products/deliverables
Delivery Also called implementation. I include testing as a part of this stage
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.
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 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
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.
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.
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.
Stakeholder Expectations The planning and documentation support the essential process of managing stakeholder (and client and user) expectations.
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.
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.
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.
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.
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:
Slower Delivery If you need something usable, fast, then Waterfall is not for you.
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.
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.
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.
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.
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
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:
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.
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.
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 ProjectManager.com 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.