What is Waterfall project management?

What is Waterfall in project management?

There is a plethora of different project management methodologies — each one best suited for a specific kind of project.

However, we can divide all PM methodologies into these two groups:

Predictive methodologies — where you outline as much of the project as you can and stick to the plan, and
Adaptive methodologies — where you break the project down into smaller chunks which you tackle one by one.

Waterfall is the posterboy for predictive PM methodologies, featuring a wholly leaner and sequential approach to completing projects.

In this guide, we’ll go over everything you need to know about Waterfall, including how it works, its pros and cons, and how you can implement it into your projects.

Table of Contents

What is Waterfall? How does Waterfall work?

Waterfall is one of the more strict PM methodologies, but it’s also straightforward.

At the heart of it, Waterfall is all about making a detailed and thorough plan, and then sticking to it. The order in which the tasks are done is also important and cannot be fiddled with.

Due to this sequential nature, Waterfall is highly resistant to change and revision.

If this sounds unreasonably restrictive, it helps to remember that different project management methodologies cater to different types of products or different industries.

Waterfall has its roots in construction and manufacturing.

If your project is to build a house, and you’ve reached the point where you’re placing roof tiles, it’s impossible to go back and change the foundation, or rearrange the plumbing pipes that run underneath it. You could do it, but it would mean undoing all the work that came after and starting over.

This is why the planning phase of a Waterfall project has to be so comprehensively thorough and why it’s impossible to make changes after the project gets underway.

However, there can be some wiggle room. If you’ve already painted the walls, changing the electricity wiring in the walls will also require you to undo some of the work, but not all of it. Strictly speaking, though, even this is frowned upon.

If these restrictions still sound too stifling for your project, then perhaps you should try using a different methodology. We’ve highlighted the differences between Waterfall, Agile, and Scrum later on.

But first, let’s learn more about Waterfall for those who are interested.

The 5 stages of Waterfall

The Waterfall moniker is meant to evoke a certain imagery that intuits the general idea behind the methodology, but we feel the name doesn’t accomplish what it’s supposed to.

If, when you think of a waterfall, you imagine a single stream of water cascading from a precipitous height, you’ll be surprised to learn that this isn’t the image Waterfall is trying to evoke.

In all honesty, Staircase would have been a better analogy, but the problem here is that staircases support traffic in both directions. This methodology, like a river, moves in one direction.

So instead, try to imagine a small stream of water that makes several smaller cascades, as if running down a staircase. After every step the water levels off for a bit, before facing the next plunge.

This is the imagery that correctly depicts the Waterfall PM methodology — a single project moving in one direction and divided into 5 distinct and linear stages:

Requirements
Design
Implementation
Verification
Maintenance

Until you’re finished with one stage, you cannot start work on the next one. And, as mentioned, backtracking to the previous stage isn’t an option either.

Some sources divide this methodology into 6 or even 7 stages, but this only needlessly complicates matters.

So with that in mind, let’s go over the 5 stages of Waterfall one by one.

Stage #1: Requirements

The first stage of Waterfall is mostly conceptual. The goal here is to understand what the client wants.

To accomplish this, the project manager gathers important information about the project and its requirements through brainstorming, interviews, questionnaires, or any similar methods. Included in these requirements gathering processes should be not only the client, but all key stakeholders as well.

If done properly, completing the requirements stage of Waterfall will result in an exact idea of what the project scope and deliverables will look like. For example, if the project is to develop a piece of software, you should know exactly what the software needs to do.

Stage #2: Design

The design stage is still mostly planning-oriented. The difference is that, having gathered the requirements, the PM can work with their team to analyze said requirements and create a comprehensive plan that they will use until project completion.

In the example of building construction, the design stage would entail deciding on the materials — quality and quantity. You still don’t have anything to show, aside from the documentation. In software development projects for example, this is where the team decides on the hardware requirements and other specifications.

Due to how detailed and well-polished the project plan and overall documentation need to be before the project can proceed to the next step, it’s not uncommon for the requirements and design stages to take a long time to complete. Waterfall rewards patience, but it also demands patience.

Stage #3: Implementation

The implementation stage is where almost all of the non-conceptual work gets done.

To follow up on the construction example given above, this is where the team would take the materials and use them to build a fully functional house. Likewise, if we’re talking about a software development project, the implementation stage would entail writing all the code in chunks, testing them, and integrating them into the system.

While this seems like it should be the most complicated stage, there really isn’t much to say about it. If the documentation compiled throughout the requirements and design stages is up to par, the implementation stage should be smooth sailing.

Stage #4: Verification

At the verification stage — also known as the testing stage — is the point at which the team takes note to verify whether the end-product works as intended and meets the requirements.

The verification stage also marks the first instance of client involvement and feedback since the conceptual phases of Waterfall.

When it comes to software projects, this is when the client and other key stakeholders would get access to alpha or beta versions of the software to see how things are shaping up.

Now all that’s left is to work out the kinks and get the client’s seal of approval.

Stage #5: Maintenance

The maintenance stage is self-explanatory.

If your job was to create a piece of software, this would mean doing bug-fixes and providing patches.

In the case of construction, maintenance would entail the handiwork of fixing the plumbing, wiring, and so on, as stipulated in the contract.

The advantages of Waterfall

While many of the advantages of using Waterfall can be discerned from the previous text, we’ve listed them out here for your convenience.

Waterfall is great for repeatable projects

The extensive documentation compiled throughout a project’s lifecycle doesn’t get thrown in the trash upon project completion. It all gets archived for future use.

And when the time comes to do a similar project, you can use the old documentation as a reliable repository of knowledge to help you anticipate risks, set milestones, and so on.

In other words, if you’ve completed a project using Waterfall once, every subsequent attempt at a similar project becomes that much easier.

This also means that knowledge stays in the organization, rather than with the individual, which leads us to the next pro.

Waterfall makes it easy to add or change team members

Comprehensive documentation really is the name of the game when it comes to the Waterfall methodology.

This documentation should detail the specific roles, responsibilities, and requirements for each team member. This makes it so that adding new team members or replacing existing ones can be done smoothly, without slowing the pace of project progress to a crawl.

Projects that rely on other methodologies — especially iterative ones — make it harder to integrate new team members, as they generally take longer to find their footing in such scenarios.

Waterfall makes it easy to measure progress

Thanks to its linear nature, gauging the progress of a project in Waterfall is quite easy to do.

With many other methodologies, the team spends a lot of time throwing things at the proverbial wall to see what sticks. Even then, since the project doesn’t progress in a linear manner, it can be hard to tell exactly how far along it’s come.

Granted, a good project manager should always have a solid idea of how the project is coming along, but with Waterfall, it’s easy to clue stakeholders in on the progress.

In addition to making it easy to measure progress, Waterfall is just overall easy to understand. The use of Gantt charts, in particular, can provide amazing insight into the rate of project completion at a glance.

Waterfall helps with setting expectations

During the requirements stage, the project manager and the client need to come to an understanding on what the project will be like. The cost, timeline, and scope of the project are all negotiated and contractually defined.

This makes budgeting and projecting a timeline for Waterfall projects rather easy, but more importantly, it prevents the project from suffering scope creep. But contractual limitations aren’t the only thing keeping scope creep off of Waterfall projects.

Waterfall is resistant to scope creep

Scope creep is one of the most prominent project risks, but Waterfall — due to its very nature — simply isn’t susceptible to it.

Waterfall does not support backtracking and redrawing plans to accommodate scope expansion.

Whereas in Agile continuous client involvement and iterative development can quickly balloon the project scope beyond the initial capacity, Waterfall projects are all but set in stone the moment implementation gets under way.

If the client changes their mind and decides they want something else, that can be arranged, but it will be a new project that will start over from ground zero.

The disadvantages of Waterfall

While Waterfall has found its footing in many industries, its identity was shaped by its roots in construction and manufacturing, leading to several disadvantages that are unavoidable if following this methodology as prescribed.

Waterfall is prone to timeline creep

Just because you have a great project plan doesn’t mean that everything will go according to plan.

Even with amazing risk management in place, setbacks are not an unusual occurrence in projects.

Unfortunately, Waterfall projects suffer more from these setbacks than projects following most other methodologies. The reason behind it is the very sequential nature of Waterfall.

In Waterfall, it’s often the case that you can’t begin work on a new task before finishing the current one. For example, you can’t add windows to a house until you’ve put up the walls.

This makes it so that a delay in any task has the potential to delay the entire project.

For projects with a strict deadline, this can be disastrous.

Waterfall suffers from lack of feedback

Using Waterfall is not unlike a trust exercise.

The client helps the project manager understand exactly what the requirements of the project are and then they don’t see anything until the verification stage. If we consider the client’s role during the requirements and design stages as providers of input, rather than feedback, then this is the first time they will be able to provide feedback.

In case something isn’t to their liking, making changes will be difficult, due to the very nature of Waterfall and its resistance to revision.

And even if we forget about the client, the internal QA testers can’t help the programmers make the code better, as their feedback will come too late in the development process.

Waterfall requirements can be based on guesswork

Speaking of providing input, a serious concern for any Waterfall project is that the client may not know exactly what they want this early in development.

It’s not uncommon for clients to give the project manager a general idea, see how things start turning out, and only later in development get a better picture of what they want and don’t want.

With Waterfall, however, the client needs to know, in great detail, exactly how they want the end-product to be.

Additionally, the project manager needs to understand how to turn these requirements into the end-product and the margin for error they have to work with is miniscule. If the requirements phase goes wrong, then the entire project will shake on this weak foundation.

How to implement Waterfall in project management?

All of the things we’ve mentioned so far make it clear that Waterfall — like all other project management methodologies — is best suited to a certain kind of project. Step one of using Waterfall in project management is finding a project that it works for.

In particular, Waterfall becomes a viable option when:

The client knows exactly what they want
The project needs to follow a linear trajectory
The project scope and deadline are contractually negotiated
The project timeline can be estimated
The project timeline, budget, and scope are fixed
The project is too risky to commit to without a solid plan
The project doesn’t allow for iteration
The project won’t receive software updates post-delivery

As for what types of projects Waterfall can work with, it can work with almost anything. Construction and manufacturing are obvious candidates, but before the advent of Agile, Waterfall was the de facto methodology used for software development. To this day, many companies still prefer to use Waterfall for IT projects and software development.

Once you’ve got the right project lined up and you’ve created the plan — for which we can’t really help you — it’s time to start with the implementation stage.

One of the easiest ways to implement Waterfall into your project management is by using Gantt charts.

This lets you create a visual outline for the project, complete with deadlines, task dependencies, role assignment, and so on.

In fact, once you put all the tasks into the Gantt chart, the chart itself should resemble the shape of a waterfall as depicted previously.

What is the difference between Waterfall and other methodologies?

We’ve mentioned already how project management methodologies can be broken down into two categories: predictive and adaptive.

The biggest difference between Waterfall and other methodologies all stem from this division.

Waterfall vs Agile

According to the Agile Manifesto, its four key values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Waterfall completely inverts this list of values: processes are respected, documentation is irreplaceable, contract negotiation is crucial, and the plan is key.

You should check out our Agile guide if you want to learn more about this methodology, but here’s the quick rundown:

Agile projects are usually self-managed, rather than helmed by a project manager.
They adhere to a cyclic approach, during which the stakeholders are involved and offer feedback every step of the way. The plan is rather basic, which in turn makes Agile projects more flexible and capable of providing quick turnover.
If you want to manage a project with Waterfall, you first spend a lot of time — months even — carefully deliberating every step of the way.
Conversely, Agile projects tend to get started much faster.

Waterfall vs Scrum

Strictly speaking, Agile is not a project management methodology.

Rather, it is a set of values which we’ve outlined. You need to follow these values to be Agile, but nowhere is it stated which steps you should follow to manage a project using Agile.

This is where Scrum comes into play.

Scrum is one of the project management frameworks built upon Agile.

Some of the other famous Agile frameworks include Kanban, XP, Lean, and Crystal.

All of these frameworks will actually provide you with a basic plan on how to manage projects using Agile.

In this sense, the differences between Waterfall and Scrum are the same as the differences between Waterfall and Agile.

In a nutshell, Scrum features a backlog of tasks that don’t need to be done in a sequential order, the Product Owner who prioritized these tasks, and the cross-functional team that tackles the backlog.

Another major difference is in the way Scrum handles development and testing. With Scrum, the project is divided into smaller parts called Sprints. Each Sprint has a development cycle of a few weeks, usually two. This is in stark opposition to Waterfall’s way of only delivering the product when it is fully completed.

Hybrid methodologies

Now if you happen to like both the more detailed planning of Waterfall and the iterative, non-sequential workflow of Agile, you can use a mixture of both.

This is known as a Hybrid methodology, also known as Agifall or Wagile.

While we won’t go into detail on how Hybrid project management work, the basics are simple to understand.

You take what’s good from Waterfall — the solid planning — and remove the bad parts — the lack of extensive QA during the implementation stage. The end result is a project management methodology that still operates off of a solid foundation, but gets going quicker than traditional Waterfall, and delivers value in smaller Sprints, all of which go through quality assurance.

Conclusion: Waterfall helps you plan for success if you already know what success means for your project

As mentioned in the introduction, different project management methodologies cater to different types of projects, and Waterfall is no different.

Having read this guide and understanding the pros, cons, and specific requirements of Waterfall, you should be able to discern whether your project can benefit from it.

Although, if you’re managing a complex project with lots of dependencies, using project management software is essential to being able to keep track of everything.

You can manage projects in Plaky right now by signing up for free.

References

APM. (n.d.). What is a Gantt Chart? Retrieved March 14, 2020, from https://www.apm.org.uk/resources/find-a-resource/gantt-chart/
Beck, K. et al. (2001). Manifesto for Agile Software Development. Retrieved March 14, 2022 from: https://agilemanifesto.org/
Douglas, H. (2009). The Traditional Waterfall Approach. UMSL. https://www.umsl.edu/~hugheyd/is6840/waterfall.html
PMTips. (2021, February 8). Hybrid Project Management: What Is It and How You Can Implement It. https://pmtips.net/article/hybrid-project-management-what-is-it-and-how-can-you-implement-it
ScrumAlliance. (n.d.). What Are Agile and Scrum and How Are They Different?. Retrieved March 8, 2022, from https://resources.scrumalliance.org/Article/what-are-agile-and-scrum-and-how-are-they-different