What Is Waterfall Methodology? Definition, Processes, And Examples
We live in a world where agile methodology is ubiquitous. From famous tech giants to small startups, everyone's using it to build their products. As you learn about agile, you may have come across the term "waterfall methodology."
Most project managers who use agile consider waterfall an outdated methodology that no longer serves a purpose in 2023. But is that really true?
As a senior product manager, I have plenty of experience in both Agile and waterfall. In defense of the waterfall methodology, let's get into the weeds with what it is, how it works, and when it's appropriate to use it.
What Is The Waterfall Project Management Methodology About?
Waterfall represents the concept of managing development projects by breaking them down into distinct phases and handling each one sequentially.
While breaking big chunks of work into smaller pieces has been a concept that humans have used since the dawn of time, the formal “birth” of the waterfall methodology happened much later—in 1970, when Dr. Winston W. Royce, a prominent computer scientist of that era, described it in his book “Managing the Development of Large Software Systems”.
Since then, it has become the main way software companies have managed their projects until the world started leaning towards Agile in the early 2000s.
What the Software Development Lifecycle (SDLC) Looks Like With the Waterfall Method
Unlike the iterative and incremental structure of agile, the SDLC for waterfall has both a distinct start and an end. It divides the entire process of creating software into five different phases or milestones and the work on one phase does not start until the previous phase is complete. Visually, it looks like this:
The work flows from one phase to another, then it reaches the bottom and the project is considered “complete”—making it visually similar to a waterfall (hence the term).
Now let’s take a look at each phase in this linear approach and understand what they are about.
Phase #1: Requirement Gathering
It all starts with gathering the requirements for the project from all stakeholders. During the requirements phase, project managers will create a comprehensive and highly-detailed document that covers every aspect of the project, from functional requirements or budget and risk plan.
Phase #2: Solution Design
Based on the requirements gathered in the previous phase, the project team will start formulating the solution and designing it. The term “design” here refers to the technical structure of the product (system design), the visual and interaction design of the product (UI/UX Design), and the physical design (if it is a physical product).
Phase #3: Implementation
This is when the actual coding happens. Your development team members will start building the product based on the deliverables that you created in the design phase.
Unlike agile, where you are free to change your project scope and design constantly, waterfall assumes that you will follow the design document and not “evolve” your product during the implementation phase.
Phase #4: Testing
As soon as the software engineering team has finished building the product, we can move on to the next phase of our project plan—testing. Your team will start checking your product for any bugs, security flaws, or user experience issues.
During the testing phase, you will also check if the functionality and the design of the final product match the project requirements documents that you created during the first two phases.
Phase #5: Deployment and Post-release Support
Assuming that your team has found and fixed all the significant issues on your product, it is time to do a release and hand your solution over to your customers and end users.
Your programmers will now move on to the maintenance phase by constantly gathering customer feedback, making the necessary fixes, and releasing new patches and updates of your product.
That’s it, your project is complete and you can move on to the next one!
So, should you use the waterfall method?
If you, the agile-minded PM (at least I assume you are), think that this methodology is out of fashion and you should never consider using it, then I (respectfully) disagree with you and argue that the waterfall approach is actually the better choice for specific types of projects.
Let me go over a couple of examples with you to prove my point.
Case Studies: The Waterfall Method In Action
As with any complex concept, some concrete examples could be helpful for understanding how the methodology works in real life. So, here are a few examples based on real projects (that I may or may not have worked on myself) to help you crystallize how the waterfall approach works in practice.
Case #1: A Customs Clearance Platform for the Government of Egypt
Imagine you are part of a company that has won the contract to modernize the international trade and customs clearance systems of a relatively large country, say Egypt.
What the Egyptian government wants is a port authority system that will manage all ships’ manifests (a customs document that contains information about all the cargo and passengers aboard that ship) that enter the various ports of Egypt.
Moreover, they want this system to directly integrate with another product they want you to build that will handle all of the customs declarations (a.k.a. SADs or single administrative documents) in the country. The form is quite complex for ordinary people to fill in, so they want you to automate it for them.
Egypt has complex taxation and customs duty system that changes rates based on the type of goods you import, their quantity, and other factors. As ordinary citizens have no idea about these rates, the Egyptian government wants your app to automatically calculate everything for its citizens based on what they have declared and let them pay online using their credit cards.
This looks like a massive undertaking, doesn’t it? Well, when finalizing the implementation details, your leadership (and even maybe the Egyptian government) will come to you, the project manager, and ask how you want to organize the implementation of this project.
Why and how you should use the waterfall method in this scenario:
Whatever you build for a national government will most likely be based on a law or a decision that the parliament has ratified. These decisions will include everything from the general terms of the project (e.g. its cost and timeline) to the minute details of how everything is going to work.
It sounds and looks like a requirement document from the first phase of waterfall, right? In fact, it does and it also means that you cannot really change implementation details, design, and requirements on the fly like in agile software development.
I used to lead such a product. One day, we realized that we can significantly improve user experience by making a couple of minor tweaks in the business logic. We immediately shared our idea with the customs authority representative that was working with us.
Well, he said no. You would think that it was a bad idea to reject such an offer, but he had a good reason why they could not do it.
Our little tweaks would mean a change in the formula that the government used to calculate taxes for a particular product. The formula was fixed in law, so changing it would mean gathering the entire national parliament and voting on it.
Case #2: The Flight Control System of the Ingenuity Helicopter
Ingenuity is the name NASA gave to the high-tech helicopter that they built and sent to Mars back in 2021. Here’s what the little fella looks like.
Well, imagine you were one lucky project manager who was in charge of developing the software for this incredible piece of tech. In particular, your team needed to write the code that would control the flight of the helicopter.
Creating a flight control system for an aircraft (especially a helicopter) is very hard. You will need to consider all of the laws of physics that interact with your aircraft during flight and calculate the necessary speed of rotating your blades, the angle of blades, and a million other things.
But your task is even more complex. Your helicopter will need to fly above the surface of another planet with an atmosphere that is 100 times less dense than what we have on Earth.
Why and how you should use the waterfall method in this scenario:
In my opinion, waterfall development is your only option here. As opposed to agile project management, in which you’re building something small (your MVP), deploying it, using it in real life, gathering feedback, and gradually improving your solution based on that feedback, the stakes are much too high with a project like this.
Can you really risk making a buggy MVP of Ingenuity and fly it 140 million miles to Mars? There is just no way anyone would agree to that.
So, you will have to build the final version of it and then test all of its systems rigorously before you have the necessary confidence to place it in a rocket flying to the red planet.
The Waterfall Model Is Alive And Well!
In fact, it is much more popular than you would have expected with half of all projects worldwide still using this development methodology.
Although the advent of agile has made the world a better place for many project managers by letting them launch products much earlier and build upon the feedback of their users, waterfall is still a highly valuable methodology that you can employ for projects with limited flexibility and a low tolerance for bugs.
I hope you liked our coverage of the waterfall methodology. If you would like to read a bit more about Agile too, here’s what I can suggest:
- Our guide on Agile Product Management.
- The compilation of best practices for Agile Portfolio Management.
- Our curated list of the best Agile Product Management Tools.
These are only three of the many guides and articles we have on product and project management. For more, subscribe to our newsletter.