The Waterfall Model & When to Use it for Project Management

Nowadays, companies want to incorporate Agile in every aspect of the business. But long before Agile came into the picture, almost everyone only knew of one way to do things in business. It’s this linear, step-by-step process called the Waterfall model that prevailed in the business operations scene. You probably have done things the “Waterfall model” way even without knowing it. It’s because it’s the most straightforward thing to do. Before complex processes such as software development and technology came into play, the Waterfall model was widely used and accepted. Let’s rediscover this age-old methodology and find if there’s still a use case for it in this modern world. 

What is the Waterfall Model?

The Waterfall model is a sequential process used to build systems and products. Progress is represented by work flowing steadily downwards like a waterfall through established phases. Hence, the name. 

Though the Waterfall model has its origins in the manufacturing and construction industries, its formal introduction and study started in software development. The Waterfall approach was formally established in the 1970s by Winston W. Royce, a renowned American computer scientist. Although he didn’t explicitly use the term “waterfall,” he detailed a waterfall-like, cascading software development process in his article, Managing the Development of Large Software Systems. Then, in the late ‘70s when T.E. Bell and T.A. Thayer published an article, Software Requirements: Are They Really a Problem?, based on Royce’s initial studies and used the term Waterfall model.

Royce, Bell, and Thayer, noted their experiences in building software for spacecraft mission planning and systems. Since then, the Waterfall model has been widely used and is the method of choice for software development companies until the early 2000s. This was right before Agile gained its roots. 

But since the birth of Agile, the Waterfall model has taken a backseat especially in software and tech companies. The model’s rigidity and linear approach is risky and a common cause for failure in highly complex and volatile environments such as software and tech. It’s interesting to note that even Royce has recognized the pitfalls of the Waterfall model in his 1970s article and has even written solutions to combat them. 

So in what processes or businesses can the Waterfall model still be applied? Or should we consider it obsolete?

When to Use the Waterfall Model

We should remember that Agile is the answer to the inefficiencies that teams often encountered in Waterfall projects. So, before we define what projects are best suited for the Waterfall model, it’s best to get a clearer picture of how it compares with Agile approaches.

Here’s a side-by-side comparison of the two:

While it seems that the Waterfall model is far from your ideal project methodology, it’s not obsolete. Depending on the project variables, the Waterfall model can be your methodology of choice. 

Here are situations where the Waterfall model is considered better over Agile approaches:

• The project has strict regulatory requirements
• Requirements and project scope are known and are not subject to change
• Budget and delivery timelines are fixed
• Low customer involvement is needed
• Technology to be used is known and well-understood

Examples of these types of projects are commonly encountered in the manufacturing and construction industries. Changes to requirements in these projects are uncommon as they will be very costly and time-consuming. Therefore, the team spends a lot of time on upfront planning, negotiations, and sign-offs. 

Projects with tasks that have been done multiple times over would lend themselves well to the Waterfall project management method. While projects with too many unknowns, frequent changes, and risks are best left for Agile methods. 

Implementing the Waterfall Project Management Model

If you find that your project meets the criteria for using the Waterfall method, don’t think that your project is doomed to fail. The fact that you have found your project variables to be more suited for Waterfall means that your project needs more control and structure. The Waterfall method  is far from obsolete. It just needs to be applied to projects that have more fixed requirements, budgets, and timelines. 

You may also find that you want to merge the Waterfall model with Agile methods. This is not far from happening. You can use systems like Kanban to come up with an Agile-Waterfall hybrid model for your project. This approach introduces an Agile layer that injects minimal interventions into your rigid Waterfall process. To help you get started, check out our Waterfall board template. Try it for yourself and see how it works.