The waterfall methodology is more than 50 years old. We ask whether it still has a place as a project management framework and what the benefits are for today’s small businesses.
In this article
The waterfall approach to project management has stood the test of time. But since it was proposed in the 1970s, many other frameworks have emerged that may be better adapted to modern technology and working practices.
In this article, we look at the pros and cons of the waterfall methodology, compare it to the agile framework, and ask what types of project it is most suited to.
What is the waterfall methodology?
The waterfall methodology is a model used in project management. It describes the stages of a project as steps that occur in a sequence, with each stage needing to be complete before the subsequent one can begin. In this sense, the output of one stage becomes the input of the next.
The waterfall model is often attributed to computer scientist Winston W. Royce, who described it in a 1970 paper on approaches to software development. In the paper, he lays out the method as an often used but flawed model, and proposes some improvements based on his experience building spacecraft mission planning software.
Royce never used the term ‘waterfall’ in the paper, but the name stuck because the process looks like a waterfall when sketched out, with work cascading down between stages just like a river flowing through several waterfalls.
Agile vs waterfall methodology
While the waterfall methodology views a project as a set of linear steps, the agile approach prioritises speed and flexibility to generate value as quickly as possible.
Agile projects divide work into ‘sprints’ of a fixed duration (usually a few weeks) where teams self-organise to complete the tasks in their sprint and deliver a version of a product that can be reviewed. They then gather feedback on the latest changes and plan for the next steps.
The focus on speed means changes can be made quickly and iteratively without teams being restricted to one project plan that was written at the start of the process. If something is not perfect after one sprint, or if requirements change, teams can go back and make fixes on the next sprint. With a waterfall methodology, the opportunities for review during the project are limited, and it can be difficult and costly to return to a previous phase.
Although both methodologies come from the world of software, they can be used for other work. However, the fact that agile generates multiple iterations of a product means that it may not be practical for certain use cases where the outcome is an expensive physical object like a building.
What are the pros and cons of the waterfall methodology?
Pros:
- Simplicity. The waterfall methodology is easy to understand and visualise. Anyone involved in the project —including developers, managers, and clients— can see the stages required and knows that each must be completed before the next one starts.
- Safety. Changes to products under a waterfall methodology are infrequent and well understood compared to more fast-moving development approaches like agile. In a software development context, for example, this means that they can be documented and communicated to users more easily. Plus, teams have more warning of what changes are coming and can assess how they will affect other systems. Any impact can be accounted for in advance, hopefully meaning fewer unexpected dependency issues upon release.
- Predictability. Under a waterfall methodology, all requirements are gathered at the start, a plan is developed, and a budget assigned. Because of this fixed structure, projects may stand a better chance of staying on budget and on schedule.
Cons:
- Inflexibility. Just like a real river, work flows much more easily through a waterfall methodology in one direction. Because waterfall projects are planned out in full at the start, it can be difficult to make changes, because it means going back to previous stages to correct work that has already been done.
- Slow progress. Waterfall projects usually depend on each stage being complete before the next one can start. If one stage is held up, this can have downstream effects, and teams may be sitting idle waiting to start work. Furthermore, it may only be possible to interact with the product right at the end of the entire lifecycle. If issues are discovered at that point, fixing them is difficult.
When should you use the waterfall methodology?
Although agile is often seen as a more ‘modern’ project management framework —and is associated with fast-moving, high-value companies like Amazon, Apple and Microsoft— the waterfall methodology is still well suited to many projects.
If a programme of work has well-defined requirements that are unlikely to change, waterfall could well be the best approach. It allows teams to plan and budget for every stage of the process and schedule resources most efficiently. It is often used on projects that have physical elements, such as those in the construction and manufacturing industries. The idea is that clients are unlikely to request a change to the layout of a building while it’s being built, whereas such requests are common in software or web development. If you have an upcoming construction project, you might also want to consider specialist construction management software.
Another area where the waterfall methodology excels is on projects where safety is a critical concern. In the medical or aerospace industries, for example, projects must undergo rigorous analysis for the eventual safety and/or compliance of the final product. In these scenarios, a well structured, highly defined process can help ensure that the requirements set out at the beginning of a project will be maintained right though until the end, deviating only within an agreed scope.
In summary, the waterfall methodology is ideal for certain projects and is still relevant in project management today. But project managers should beware of the advantages and disadvantages of the approach and understand when (and when not) to use it.
