Waterfall is a project management approach where a project is completed in distinct stages and moved step by step toward ultimate release to consumers. You make a big plan upfront and then execute in a linear fashion, hoping there won’t be any changes in the plan.
When you take traditional project management and apply it to software development, you get Waterfall. As such, no one invented waterfall - instead, we gave it name once we realised that there are others ways to manage projects (like agile project management).
Waterfall was the first software development methodology, inherited from manufacturing and construction industry where you can’t afford to iterate (after you’ve built a tower or a bridge you can’t go back to “improve” the foundation). But because software is prone to frequent change, waterfall is not the best solution.
Waterfall is often mentioned alongside Agile and stands in contrast to it. The main difference between them is that waterfall doesn’t react well to frequent changes, which is why it gets a bad reputation in software development community, where frequent changes are the norm.
Phases in waterfall projects
All tasks on waterfall projects are grouped by type of activity and each projects follows the same phases:
- Requirements - where we analyse business needs and document what software needs to do
- Design - where we choose the technology, create diagrams, and plan software architecture
- Coding - where we figure out how to solve problems and write code
- Testing - where we make sure the code does what it supposed to do without breaking anything
- Operations - where we deploy the code to production environment and provide support
Once you put all the activities on a Gantt chart, you get something that looks like slopes of a waterfall, hence the name.
Usually 20–40% of the time is spent on requirements and design, 30–40% on coding, and the rest on testing and operations.
Activities on waterfall projects have to happen in the exact order and one set of activities can’t start before the previous one ends. This is why planning is the most important thing on waterfall projects: if you don’t plan right, a phase will be late and will push every other subsequent phase, thus putting the whole project over deadline.
The problem with using waterfall method on software project is that planning is very tricky in software development. You can never be 100% sure how much time you’ll need on something or how much time you’ll spend debugging. As a result, waterfall is risky.
Advantages of waterfall
Because you can’t go back to a previous activity, you’re forced to create a comprehensive documentation from the start, listing all the requirements you can think of.
Knowledge stays in the organization
When you have extensive documentation, knowledge won’t get lost if someone leaves. Also, you don’t have to spend time on training new members as they can familiarise with the project by reading the documentation.
Team members can better plan their time
Because everyone knows in advance on what they’ll work, they can be assigned on multiple projects at the same time.
Easy to understand
Waterfall projects are divided in discrete and easily understandable phases. As a result, project management is straightforward and the process is easily understandable even to non-developers.
Client knows what to expect
Clients can know in advance the cost and timeline of the project so they can plan their business activities and manage cash flow according to the plan.
Client input not required
After requirements phase, client input is minimal (save for occasional reviews, approvals, and status meetings). This means you don’t have coordinate with them and wait for when they’re available.
Easier to measure
Because waterfall projects are simple, it’s much easier to measure your progress by quickly looking at a Gantt chart.
Products have a higher cohesion because during the design phase you know everything that must be taken into account. There is no one-feature-at-a-time problem that leads to usability problems down the road.
Disadvantages of waterfall
No going back
Once you’re finished with one activity, it’s difficult and expensive to go back and make changes. This puts a huge pressure on the planning.
No room for error during requirements phase
Everything relies heavily on the requirements phase and if you make an error, the project is doomed.
Once one activity is late, all the other activities are late too, including the project deadline.
QA too late to be useful
Testing is done at the end of the project which means that developers can’t improve how they write code based on QA feedback.
Bug ridden software
Because the testing is done at the end, most teams tend to rush the testing in order to deliver the project on time and hit their incentives. This short-term wins lead to sub-par quality and long-term problems.
Not what the client actually needs
Most of the time, clients can’t articulate what they need until they see what they don’t need. If the client realizes they need more than they initially thought, the project plan will need a major overhaul (as well as the budget).
Designers can’t foresee all the problems that will arise from their design, and once those problems surface, it’s very difficult to fix them.
On what types of project you should use Waterfall
Waterfall is suited for projects where:
- budget, requirements, and scope are fixed (eg. you’re building a one-off project which doesn’t need further development)
- you can accurately estimate the work (you’re familiar with technology and you’ve done the same work before)
- you can’t afford to iterate (eg. you’re building a heart rate monitoring software)
- project is innately low-risk (you’re building a clone of something that already works)
- project has a hard ship date (eg. you have to ship a video game by Christmas)
- your users can’t or won’t update software (doesn’t apply to web applications where updates are seamless)
You shouldn’t use waterfall:
- where a working prototype is more important than quality (eg. you first need to test if there’s a market demand)
- when you don’t know what the final product should look like
- where client doesn’t know exactly what they need
- when the product is made for an industry with rapidly changing standards
- when you know you won’t get the product first the right time and have to incorporate user feedback
- when your users are happy with v1.0 and you can ship additional features as time goes on
Whether you’ll use agile or waterfall doesn’t matter on your preference but type of project and your customer/client. While strictly speaking agile is better for software development (see the statistics here), if you can’t iterate, you have to use waterfall.
Waterfall is not that different from Agile
Waterfall is always mentioned as the antithesis to Agile, which makes sense. After all, waterfall projects have a hard time dealing with changes while agile projects welcome change. At least in theory.
The truth is, no matter what methodology you use, change is not a good thing. Change always means additional scope, delay, and expenses. Agile is better at minimising the effects of change, but they still happen. Also, agile teams have the culture where change is OK, which is maybe the most important benefit of being agile.
But once you scratch behind the surface and look both from purely process perspective, waterfall is very similar to agile.
Once you break down any agile workflow, you’ll still get a set of activities that follow one another, which eerily resembles Waterfall. And if you treat waterfall projects as smaller phases within a big project, you’ll end up with agile.
In other words, activities on a project are waterfall and if you treat the whole project as a series of iterations, it’s agile.
Whether you’re agile or waterfall ultimately depends on whether your client expects the first version to be bad. And waterfall projects are projects where the client decided on zero iterations.
In agile projects, the number of iterations is decided on by the customer. Because things are all done within an iteration in agile, the logical assumption was that an iteration equaled a project. But an iteration is more properly referred to as a phase or subphase of the project. - PMI
As you can see, agile still fits in the traditional project management, only the point of view changes. Instead of treating each iteration as a separate project, iterations are just phases in one big project.
The real difference between the waterfall method and agile is that in waterfall the clients is heavily engaged at the beginning of the project and then their engagement declines; while in agile, the client is constantly engaged.
So what this all means in practice? It means no organization is purely agile or waterfall. Agile and waterfall are more about the culture and type of work the organization does than how they do it. You’ll find that most organizations divide the project into waterfall milestone but work according to agile principles between those milestones.
A problem common with comparing agile and waterfall is the labeling. Few, if any, companies are purely “agile” or “waterfall”. They are more mindsets that encompass a wide variety of practices and approaches to development. Labels are convenient for helping make an argument, often with cute little straw-man statements to help reinforce preconceived notions. - Clinton Keith
- Waterfall project management
- Fundamentals of Agile project management
- Advantages and disadvantages of Agile project management
- Introduction to Scrum
- Extreme Programming (XP)
Other posts on Agile project management
- A practical guide to project planning
- Keeping projects on the right track
- Project manager roles and responsibilities
- When to hire a first project manager
- How to choose the right project management methodology
Posts on project management
- The Complete Guide to Managing Digital Projects
- Fundamentals of Agile Project Management
- Kanban: A Quick and Easy Guide to Kickstart Your Project