For many people in some parts of the world, the waterfall model is completely unknown—even though they’ve probably been using it for years without knowing what it is called. It is the original project management model used in the construction and manufacturing industries for decades, perhaps centuries.
And that’s where companies getting into the then-emerging computer industry turned when they needed a more formal approach to managing complex projects in the 1950s and 1960s. The waterfall method was used for hardware and software development projects and eventually became the default methodology in both.
What is the waterfall method?
You can probably best understand the model as a linear or sequential approach to project management and the software development life cycle (SDLC). It is a step-by-step approach where each step is irreversible and must be completed before the next one can begin. The flow from one stage to the next mimics a waterfall, hence the name.
In construction, the steps might be design; pouring the foundation; erecting the skeleton; constructing walls and floors; etc. The waterfall methodology is also often used in process manufacturing, where separate ingredients are mixed to create new products or ingredients until a product reaches its final state.
In the software development process, the waterfall model is suitable when an application needs to work all at once. And when failure to work immediately could increase the risk of losing customers, or worse.
The common denominator is that all these examples are instances of projects with well-defined, predictable, and specific documentation and deliverables that need to work as a unit all at once. There are also certain prerequisites. To use the waterfall model, a project or activity should have the following:
- Clear and fixed deliverables;
- Adequate resources;
- An established timeframe;
- Use tried-and-tested technology; or brand new technology that is tested during implementation, and
- Be unlikely to need significant changes in features along the way.
And a typical waterfall project will follow the timeline and step through five clear phases:
- The requirements phase scopes the requirements
- The deliverables are designed in the design phase
- The implementation phase involves building the deliverables
- The testing phase verifies the project's deliverables work as designed
- The maintenance phase keeps the system functioning
Advantages of the waterfall method
There are three main benefits of using the waterfall method. The first is clarity. Because the scope is defined up front, clearly documented, and signed off, the process of running the project is relatively straightforward and measured.
It also means that costs are easier to contain, timelines more readily met throughout, and few, if any, unwelcome surprises can derail the project. That leads to the second advantage: predictability. Because you keep changes to a minimum, additional costs incurred to fix and alter designs remain low too.
 |
The third advantage is accountability. The structured approach means that everyone involved understands exactly who needs to do what and by when. The detailed documentation also helps here by providing a useful reference for team members.
Disadvantages of the waterfall method
There are some constraints associated with the waterfall model. The first is the +rigid approach it has to change requests. This is to ensure that a change in scope must be evaluated for how it will impact cost and schedule, and approved to move ahead.
But in an ever-changing modern world, this could also be a blessing. If you face the possibility of hitting the restart button on your project, you’ll need to consciously reassess the impact of any changes on the budget and schedule.
A second disadvantage is that planning can take up considerable time. This is because the waterfall model requires a detailed breakdown of the tasks and deliverables before you can get started. You have to know what you’re building before you start doing that.
This can be tricky to do up front, and the usual response is to budget time generously, often more so than needed. It can also result in a much longer project timeline than should be required and can have a knock-on effect on costs. Time is money, after all. But, this is right for an airplane, and may be wrong for flexible user software in a marketing app.
Finally, the waterfall model often limits external stakeholder engagement to periodic reports (weekly or monthly) major reviews. So feedback can be sporadic, or limited to video conferences. The day-to-day involvement of stakeholders in an Agile project offers a stark contrast.
But this is not entirely true. External stakeholders are very involved in significant, decisive points of a waterfall project. For example, airlines are often heavily engaged with Boeing’s design of a new airplane, especially the interiors. And the FAA (Federal Aviation Administration) is closely involved in defining that aircraft’s safety and control specifications.
The modified waterfall method
To deal with some of the “disadvantages” described above, the modified waterfall method was developed. It retains the sequential nature of the original model but adds some flexibility by allowing project phases to overlap with the previous phase.
As small a modification as this is, it introduces a lot of flexibility because it means that a lot of tasks can function concurrently. This means that any observed defects in the planning can be corrected or removed earlier rather than only in the formal testing towards the end of the project.
In software development
The waterfall method in the SDLC (Software Development Life Cycle)
In the early computer industry, there was no clearly defined system for developing software, and the need for one was quickly realized. Construction and manufacturing were leading industries then, and programmers adopted (and adapted) the unnamed project management model used in those industries.
This process was first documented for use in the SDLC in a 1970 paper by Dr. Winston W. Royce, who worked at the Lockheed Software Technology Center. But he didn’t name it, and it’s unclear, even today, who did. We know that the name came from how each phase cascades into the next, flowing steadily down like a waterfall.
 |
However, even back then, Royce had reservations, particularly about the testing only happening toward the end of a project. These reservations were shared by other systems programmers of the time, eventually leading to the modified waterfall model mentioned above.
When to use it
The waterfall model is generally appropriate to use in software development under certain conditions:
- When you have a very clear set of project requirements that features nothing ambiguous.
- When the project requires minimal input from external stakeholders such as customers.
- When you’re developing the software in a stable development environment.
- When your development team has the skills to deliver and is available.
- When you’re using tried-and-tested tools and techniques.
- When the software modules contain considerable inter-dependencies.
But when more complexity creeps into any of these factors, it may be better to go for the modified waterfall method instead.
Who uses it
This methodology perfectly fits teams and projects with fixed or unchanging requirements that are clearly documented initially. A key characteristic of the waterfall model is its high degree of process definition with little or no output variability. This makes it a good choice if your project has constraints on costs or time.
It is also a valuable model for software development teams and project managers who must develop an application that must work out of the box; that is, it can’t be delivered incrementally.
Why they use it
The waterfall model is a good approach to use in the SDLC when the end user or client is involved in a formal, well-defined review and comment process. By bringing the client or users in only when needed, the development team can move very quickly through the different phases of the project.
Also, because the model features a clearly planned series of sequential phases, the team can plan the development in clear steps, each with a due date and milestone deliverable. This obviously also works well where cost and time are critical factors in determining success.
In project management
The waterfall method in projects
Although the methodology was first used in construction or manufacturing, nobody seems quite sure which of them came first. Or perhaps it emerged organically in both at more or less the same time. Wherever the origins are, the waterfall model is still the go-to approach for project management in both industries.
 |
And it has also been adopted in businesses of other types. One that stands out is the IT industry, which has long been the gold standard for rolling out new systems or applications.
When to use it
Not surprisingly, the waterfall methodology is the best one to use for more general projects when:
- You are clear about project goals and objectives.
- You can see a clear linear progression for the project.
- You are working in a stable environment.
- Your project resources have the skills and are available when needed.
- You’re using bog-standard (ordinary) tools and techniques.
Who uses it
Project managers and their teams select the waterfall model across many industries and even for deploying new IT systems. And they choose it because it helps them ensure their projects are completed within budget and on time.
But perhaps most importantly, and as noted above, the waterfall methodology calls for goals and deliverables to be clearly defined and documented upfront. All of this follows a clear hierarchy:
- Project scope is used to define the deliverables – what has to be created to deliver the scope.
- The deliverables are split into pieces to define the work breakdown structure (WBS).
- The WBS provides detail down to individual task level.
- The order in which the tasks are to be performed is specified.
- Resources are assigned to every task.
- Then, based on the level of effort and availability of resources, the schedule is drawn up.
- And then the budget can be finalized.
Of course, some of these things can be done at the same time (or you could choose to use a hybrid waterfall model), but the progression is quite clear.
Why they use it
Transparency. The WBS mechanism in the waterfall approach provides a useful mechanism to break down the deliverables for the project into bite-sized chunks. These chunks then split out into project tasks, each of which will have durations assigned and may have dependencies.
The durations are often determined by the resources assigned and level of effort to complete the tasks.
That informs the scheduling process and, once the project schedule is created, project progress can easily be monitored at a high level with the aid of visually-pleasing and informative Gantt charts
But where the waterfall method really comes into its own is when the deliverable only works as a whole. You can't deliver a bridge to stakeholders (users, drivers) iteratively. Or a plane, or a highway (even though you grade and pave it iteratively). So when you need to deliver a project all at once, you use the waterfall model.
Agile vs. waterfall
On the other hand, when your project is expected to deliver usable elements in an incremental fashion, you’d use the Agile approach. This is especially useful when you can't define all your requirements up front because they aren't known, or have to evolve over time.
In software development
The Agile methodology to project management is frequently preferred for software development because it is a pursuit that can require flexibility and adaptability. But sometimes, a project will also need to tick boxes for clear-cut goals and planning, which is when a hybrid approach is often best.
 |
It can be the modified waterfall model mentioned above, or it could be something that reduces overlap and redundancy. The Business Intelligence Guidebook recommends a hybrid approach using the incremental development methodology and an iterative development model such as Agile.
In project management
By their very nature, projects in disciplines other than software development tend to be more settled. They are also usually implemented in more stable environments using tried-and-tested tools, techniques, and technology. That makes them almost tailor-made for the waterfall methodology.
But sometimes an Agile approach or hybrid model is a better bet. The choice is a function of the project itself, with the key determinant being feedback. If project success can be enhanced by input from users or team members performing individual tasks, then some agility is a requirement.
When the waterfall is king
The primary advantage of the waterfall methodology is that it offers clarity, predictability, and comprehensive documentation. If that’s what you need, whether you’re engaged in software development or project management, then waterfall is the methodology for you. But if not, you may want to look into Agile project management.
But either way, Motion is an online tool that embraces the best of both methodologies and can be used in either discipline. It’s a solution that you can use to simplify and automate the process of managing your project team.
It facilitates the waterfall model and supports Agile project management, allowing you the best of both worlds. For example, you could use a uniquely Agile Kanban board as a tool to manage your waterfall project. Whether your tasks are Waterfall or Agile, Motion can manage the delivery of tasks to your team according to priority, deadline and resource availability. Check it out by trying Motion for free for seven days.
