The 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 linearly, 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 a name once we realized there are other ways to manage projects (like agile project management).
Waterfall was the first software development methodology, inherited from the manufacturing and construction industry, where you can't afford to iterate (after you've built a bridge, you can't go back to "improve" the foundation). But because the software is prone to frequent change and issues, Waterfall is not the best solution.
Waterfall is often mentioned alongside Agile and stands in contrast to it. The main difference is that Waterfall doesn't react well to frequent changes, so it gets a bad reputation in the software development community, where frequent changes are the norm.
Project Management Methodologies and Frameworks
Phases in waterfall projects
All tasks on Waterfall projects are grouped by type of activity, and each project follows the same templates:
- Requirements - where we analyze business needs and goals 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 is supposed to build without breaking anything
- Operations - where we deploy the code to a production environment and provide support
Once you put all the activities on a Gantt chart, you get something that looks like the 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 Waterfall project planning is the most important thing in these projects: if you don’t plan right, a phase will be late and push every subsequent phase, thus putting the whole project over the deadline.
The problem with using the Waterfall methodology on a software project is that planning is tricky in software development. You can never be 100% sure how much time you'll need on something or how much you'll spend debugging. As a result, Waterfall is risky.
Advantages of Waterfall
Extensive documentation
Because you can't return to a previous activity, you're forced to create comprehensive documentation from the beginning, listing all the requirements you can think of.
Knowledge stays in the organization
With an extensive level of documentation, knowledge won't get lost if someone leaves. Also, you don’t have to spend time training new members, as they can familiarize themselves with the project by reading the documentation.
Team members can better plan their time
Because everyone knows in advance what they'll work on, they can be assigned to multiple projects simultaneously.
Easy to understand
Waterfall projects are divided into discrete and easily understandable sequential phases. As a result, the project management processes are straightforward and easily understandable even to non-developers.
The 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 is not required
After the requirements phase, client input is minimal (save for occasional reviews, approvals, and status meetings). This means you don't have to coordinate with them and wait for when they're available.
Easier to measure
Because Waterfall projects are simple and linear, it's much easier to track and measure your progress by quickly looking at a Gantt chart.
Better design
Products have a higher cohesion because, during the design phase, you know everything that must be considered. 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 finish one activity, it's difficult and expensive to go back to the previous stage and make changes. This puts huge pressure on planning.
No room for error during the requirements phase
Everything relies heavily on the requirements phase, and the project is doomed if you make an error.
Deadline creep
Once one activity is late, all the other activities are late, too, including the project deadline.
QA is too late to be useful
The testing stage comes 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 it in order to deliver the project within the deadline and hit their incentives. These 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 want. If the client realizes they need more than they initially thought, the project plan will undergo a major overhaul (as well as the budget).
Unexpected problems
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 projects should you use Waterfall?
The waterfall is suited for projects where:
- budget, requirements, and scope are fixed (e.g., 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 and use Scrum (for example, you're building a heart rate monitoring software)
- project is innately low-risk (you're building a clone of something that already works)
- the project has a hardship date (e.g., 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 a waterfall:
- where a working prototype is more important than quality (e.g., you first need to test if there’s a market demand)
- when you don't know what the final product should look like
- where a 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 at 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 the type of project and your customer/client. While strictly speaking, the implementation of Agile is more suited to software development, if you can't iterate, you must use Waterfall.
Agile vs. Waterfall
The Waterfall project management methodology is always defined as the antithesis of Agile, which makes sense. After all, Waterfall projects have difficulty dealing with changes, while agile 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 minimizing the effects of change, but they still happen. Also, Agile teams have a culture where change is OK, which is the most important benefit of being Agile.
"The key to successful project management is to adapt. If you're constantly evolving, you are perfectly suited to project management's nature, as it is a beast that is continuously unknown. Success rests on the shoulders of your ability to plan ahead and adapt." — Kalila Lang, DigiSomni
But once you scratch the surface and look at both from a pure process perspective, Waterfall is similar to Agile.
Once you break down any Agile workflow, you'll still get a set of activities that follow one another, which resembles the steps of 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 those where the stakeholders decide 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 traditional project management, but the point of view shifts. Instead of treating each stage as a separate project, iterations are just phases in one big project.
The real difference between the Waterfall project management methodology and Agile is that in Waterfall, clients are heavily engaged at the beginning of the project, and then their engagement declines, while in Agile, the client is constantly engaged.
So what does this all mean 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 a 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
Variations of the Waterfall Model
Over time, Waterfall got modified to fit the various needs of its users and find the best approach according to the industry. Several variants were introduced, such as Sashimi, the V-shaped model, iterative, Big Bang, Spiral, incremental, and some hybrid models. The original was nicknamed the Classical Waterfall method as a way to distinguish it from its successors clearly.
- The Iterative model introduces some Agile elements to Waterfall. Instead of strictly developing the project sequentially, it allows feedback loops that affect the next iteration. Each iteration ends with testing and stakeholder feedback so the product can be perfected through iterative phases.
- The Sashimi Waterfall model is also known as the Overlapping Waterfall model because, just like the slices of food in Sashimi, it lets phases overlap each other. Some projects can benefit from phases such as requirements and design to happen simultaneously, but issues like miscommunication and inconsistency can easily arise.
- The V-shaped model is interesting because it combines various elements from the previously mentioned Waterfall variants. It features two parallel tracks where one is the verification and the other is validation, while the coding phase joins the two sides in the middle. It’s not advised to use it on complex endeavors because of its inflexibility, but it’s a good fit for projects in the medical industry.
- The Big Bang Waterfall model is based on the physical theory and is just as simple. In short, this method doesn’t require any planning and has no process. All the resources come together and produce an output that may or may not be what the client wants. This model can be applied to very small projects where the customer doesn’t have clear requirements.
- The Spiral model follows the Classical Waterfall model but allows the product to be developed and released incrementally. It minimizes the high risks of strict Waterfall development that requires the product to be released only at the end of the project, and it’s much more adequate for the software industry today.
- The Incremental model is another variation that adapts Waterfall to modern software requirements. It doesn’t demand as much documentation, lowers the risks, and has more flexibility. It introduces testing at the end of each iteration and allows overlapping. This model is also a mix of Agile and Waterfall.
Project Management Software to Manage Waterfall Projects
Traditionally, Waterfall projects were drawn up on large boards and updated regularly. Modern solutions include project management tools like ActiveCollab that make the job much easier for managers. In ActiveCollab, you can create projects, set up their target budget and invite all the necessary people. The notes can help you define and document requirements, so you're on the same page with your team and clients.
You can create a task list for each Waterfall phase: design, coding, testing, and operations. Within these task lists, you can split up the work into smaller, more manageable chunks. Each task can be described in detail, assigned, and enriched with information and attached files. The comment section lets you and your team discuss among yourselves or with the client how the task is progressing and learn whether you're headed in the right direction. To avoid confusion, you can @mention the specific person you're addressing. Once you set the due date, they'll appear in the project timeline, and you'll be able to visualize all the dependencies between connected tasks.
The integrated Stopwatch lets your team track time on individual tasks and projects. You can set an hourly rate for each job type, and when it's multiplied by the tracked hours, it will be recorded as the project cost. The Project Info lets you track the costs and how close you are to reaching the target budget.
The thorough ActiveCollab reports let you overview where the time and budget went throughout all your projects. In time, you'll be able to compare the estimated vs. tracked time so your next predictions can be more precise, giving you the possibility to plan future projects accurately.
