Waterfall methodology guide: Is it right for your team? [+templates]
Your all-in-one guide to visualizing, managing, and planning a project with waterfall.
Is the waterfall methodology right for your team?
The waterfall methodology is a relatively simple way to visualize, manage, and plan a project. It has fallen out of favor in recent years due to the rise in the adoption of the Agile methodology, but it still has its uses.
For busy project managers, the waterfall approach can save a ton of time and brainpower with its simple, clear layout. But this simplicity can be a drawback when your project is complex and requires iteration.
Before you use the waterfall method, you need to understand its nuances, advantages, and disadvantages, as well as how it compares to Agile.
What is the waterfall methodology?
The waterfall methodology is a project management approach where you organize a project into distinct, sequential phases. Each phase contains tasks that relate to the objective of that specific stage.
There is no overlap between phases. The project cannot move on to the next phase until all the tasks and deliverables of the previous phase are complete.
When you lay out all the stages of a waterfall project, you end up with a graphic like this one:
also are handy for project managers using the waterfall method. In Coda, you can easily turn your table of tasks into a timeline view — any updates made in the table are automatically reflected in the Gantt.
Create a set of MVP mocks to share with stakeholders.
Present mocks and create a form to collect feedback. Ask for feedback via Slack and email.
Use mocks and feedback to create a first iteration of the design.
There are no rows in this table
Each stage flows down into the next one, creating a waterfall-like effect (hence, the name). Collecting project requirements leads to designing solutions to meet those requirements, which then leads to creating those solutions, and so on. Within this workflow, the project requirements are dependencies for the design phase, where you can't start designing until the requirements document deliverable is complete.
The waterfall methodology is kind of a "default" in project management because it's relatively easy to grasp compared to other methods, like Agile. There are two reasons why:
Most people have already encountered the waterfall model or other models it inspired.
The waterfall process has been around since the 70s,
. Later project management models and methods iterate on the waterfall model or try to fix it with a new approach.
It's clear, linear, and logical.
On its face, it just makes sense to lay the steps to completing a project in a sequence of distinct stages. Its simplicity is both a strength and a weakness, though (more on that in a little bit).
Because it's a relative default, many different industries, from construction to healthcare to software development, use the waterfall methodology. Whether it's right for you depends on your project and the stages you need to follow to complete that project.
The five stages of waterfall project management.
No matter how or where project managers use it, there are five phases the waterfall methodology follows: the requirements phase, the design phase, the implementation phase, the testing phase, and finally, the deployment and maintenance phase.
1. The requirements phase.
The first step is to gather all the requirements for the project from its stakeholders. These requirements need to be specific, and you need to think about them in terms of the
Do not be abstract. If you're not specific about what needs to happen, there will be confusion later on when it comes time to start building and testing. Once all requirements are gathered and specified, you're ready to move on to the next phase.
A requirement could be, "We need the button to change from blue to red." Being too abstract in this case would be something along the lines of, "We need more people to click the button."
2. Design the specifications.
Once you gather
the requirements from the previous phase, you can start designing the solutions and specifications. Two sub-stages typically come up at this point:
or a pen and paper. All you're doing is laying out what you know about the requirements and what you can do about them.
Physical design is where you turn your logic into actual specifications within your hardware or software. Put in "real people" terms: you're setting up all your tools so you can start working. You can think of this stage as a sort of
One thing to notice about these first two phases (requirements and design) is that you haven't built anything yet. It's all meticulous documentation and planning, often with specific requirements documents and design documents that every team member can access. The next phase is where you start putting things into motion.
If you need to change a button from blue to red, the designer needs to pick a specific shade of red, the front-end developer will need access to change the color, and you'll need some sort of analytics to measure the impact of this change.
3. The implementation phase.
Only now, after you've laid out and documented all the requirements and designs, can you start implementing. The tasks that make up this stage depend heavily on your specific project, but in general, it's when the project is put in the hands of the experts to do the job required of them.
The front-end developer changes the color of the button to red.
4. The testing phase.
The testing phase is where you test your implementation to ensure it answers every requirement. This stage also depends heavily on the project itself.
The documentation you've created up to this point is helpful during this phase because you can not only check if the requirements are met but also see the reasoning behind certain choices from the design phase.
Check if the button is indeed red instead of blue.
5. The deployment and maintenance phase.
If your implementation does indeed pass the test, it's time to deploy and maintain. Periodically you'll circle back to make sure the project is still fulfilling the requirements you initially laid out.
Push the button color change to make it live and ensure it stays red throughout future website updates.
What is the difference between the waterfall methodology and the Agile methodology?
As we've touched on before, two of the main approaches to project management are the waterfall method and the Agile method. Both are great for different reasons, and each has its own specialty.
The waterfall methodology is a rigid, standardized approach that's best for shorter, well-defined projects where tools in use and variables are well known. The Agile approach is a flexible approach that's best for ambiguous, complex projects where not every variable is known, like software development projects.
Real quick: the Agile method breaks a project up into sprints, which typically last two weeks. In that time, the cross-discipline team practices daily communication to troubleshoot roadblocks. At the end of the two weeks, the team completes one specific phase of the project. The idea is that implementation and iteration start immediately, which suits many businesses' software development life cycle.
Here's one metaphor we think of when differentiating waterfall and Agile:
The waterfall methodology is like a train, where once you set it on its track, it goes very fast and smooth. But if you need to alter your route along the way, you're in for a difficult, time- and resource-consuming ordeal.
The agile methodology is more like a fleet of semi-trucks where each truck can alter its route along the way to avoid traffic jams, construction, and anything else it runs into.
Advantages of the waterfall method.
The waterfall method is great for smaller, focused projects where you know what needs to happen, why it needs to happen, how you'll make it happen, and the roadblocks you're likely to encounter along the way.
The waterfall method is relatively simple and easy to understand. This means every stakeholder gets a clear view of what's happening when and why.
It's easy for project managers to manage. Each stage is sequential, precisely defined, and limited. This makes it easy to arrange and assign tasks and milestones.
Documentation is a priority early on, so onboarding new team members is easy. All the requirements, reasoning, and plans are laid out precisely.
Disadvantages of the waterfall method.
The waterfall method requires you to know a lot about the project before you start. This amount of knowledge and time to define all these things are luxuries many fast-moving, iterative teams just don't have.
The waterfall methodology requires your stakeholders to know what they want. If they're at all abstract and uncertain or if those requirements change, the waterfall methodology may break down.
The specific stages can be restrictive. Not all projects can follow a step-by-step sequential flow, and many tasks may fall into a grey area that doesn't clearly fit within the requirements or design phase, for instance.
Actual work towards the completion of the project doesn't get done until the implementation phase, which is late in the project's lifecycle. If any technological or process bottlenecks pop up at this stage, it may already be too late to change course.
Advantages of the Agile method.
The Agile method is excellent for complex projects with unknown variables and the potential to change as they develop.
keeps everyone up-to-date no matter how much things change.
Sprints allow the project team to tackle pieces of the project bit by bit, which means you're implementing solutions on week one rather than much later.
Disadvantages of the Agile method.
For simple, straightforward projects, the Agile method may be overkill. Managing an Agile project is a lot of work and may eat up peoples' time rather than keeping them focused on work.
The Agile method is complex and requires everyone to be on board with its processes. Concepts like sprint planning, retrospectives, and more can be difficult for every stakeholder to understand quickly.
Its flexibility can also lead to ambiguity. Because it can accommodate changes in requirements and direction, those things can sometimes be ill-defined and unclear.
Because the focus is implementing and iterating along the way, documentation can become an afterthought if teams aren't careful. This can make onboarding new team members difficult.
How do you pick the right project management methodology for your team?
Between waterfall and Agile, the correct project management methodology for your team depends on the project itself. If it's a well-defined, straightforward project, try waterfall. If it's a less well-defined, ambiguous project (like a software development process), try Agile. But, as with anything in project management, there are a few things to consider first.
Consider your requirements.
If your requirements are clear, the waterfall method is a good choice. You can lay out your requirements, design solutions, implement, test, and deploy in a simple, sequential process.
If you still need to figure out your specific requirements, use the Agile method. The way Agile is laid out allows you to iterate towards a goal rather than having every aspect laid out from the get-go.
Consider your deliverables.
If your deliverables are known and predictable, use the waterfall method. Because each stage has an exclusive focus, you can categorize your deliverables by each phase and your overall timeline.
If your deliverables aren't known and depend on outside factors, use the Agile method. At the very least, you can start with a known requirement in the first sprint as you feel out and explore what else is needed.
Consider the project scope and timeline.
If your project scope and timeline are well defined and repeatable, use the waterfall method. Its distinct phases and clear expectation can keep everyone on time and within scope.
If the project's scope, timeline, and processes are all subject to change and iteration, use the Agile method. Because it's broken up into sprints, an Agile project could go on as long as needed to complete.
6 waterfall methodology templates you can use right now.
A quick internet search will result in hundreds (ok, probably thousands) of tools to help you implement the waterfall method. But I’ve done a bit of research for you. Here are 6 of my favorite waterfall-related Coda docs that you can start using right now:
Get Things Done with a template to help you schedule tasks. Plus, keep track of notes, meetings, and retrospectives. This doc gives your team a single space to build out an entire project. So no more toggling back and forth between tools — or wondering where you last saw a project update.
And what about projects that have inter-related tasks? Simplify your pipeline by clearly laying out your plan and then visualizing the execution phase. I highly encourage you check out this template’s bonus feature: automated notifications.
While this template isn’t just about the waterfall method, I hope you’ll find its simplicity helpful for managing projects generally. You’ll find the Gantt chart on the roadmap page, but don’t be afraid to expand the format beyond the roadmap to smaller task sets. And try bringing it to the front page to keep the timeline top of mind.
Speaking of roadmaps, here’s a template to help you balance your waterfall of tasks and the potential resources you can allocate to each. Your team will appreciate the effort score assigned to each task — encourage them to be honest and realistic!
Waterfall methodology FAQ
What is the main difference between waterfall and Agile?
The main difference between the waterfall and Agile project management methodologies is how defined each variable is. The waterfall method has clearly defined requirements, sequential stages, and deliverables. The Agile approach is iterative and allows for more flexible definitions for requirements and deliverables that can change depending on internal and outside factors.
Can my team switch from waterfall to agile easily?
With the right project management tool, your team can switch project methodologies easily. To do so, use a tool like Coda, which allows you to create any document or project management tool you need out of a legos-like doc building interface.
Is the waterfall methodology still commonly used?
Yes, the waterfall methodology is still used, especially for well-defined, straightforward projects.
Want to print your doc? This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (