The pros and cons of waterfall methodology

If you’ve researched project management methodologies before, the waterfall methodology has probably come up. On lists of popular, efficient project management methodologies, waterfall sits comfortably among Agile, Scrum, Six Sigma, and Kanban. Dr. Winston Roye first defined the methodology in 1970 in a paper about inefficiencies in software development projects, but no one is credited for individually creating the methodology. 

A half a century after it was identified, waterfall still has relevance in the modern business world—but it shouldn’t be used indiscriminately. Read on to learn more about the pros and cons of the waterfall model and to see how Lucid can help your team apply this approach to your next project.

What is the waterfall project management methodology?

Simply put, traditional Waterfall project management is a sequential, linear process of project management consisting of several distinct phases. No phase begins until the prior phase is complete, and each phase’s completion is terminal; Waterfall management does not allow you to return to a previous phase. The only way to revisit a phase is to start over at phase one.

If waterfall methodology sounds strict, that’s because the system’s history demanded it. Waterfall project management has its roots in non-software industries like manufacturing and construction, where the system arose out of necessity. In these fields, project phases must happen sequentially; you can’t put up drywall if you haven’t first framed a house.

As you can imagine, proper planning is a must in the Waterfall system. A project’s requirements must be clear upfront, and everyone involved in a project must be well aware of those requirements. Each team member should also understand what their role will be in the project and what that role entails.

All of this information must be thoroughly documented and then distributed to everyone on the project. Team members will refer to the documentation you provide throughout the process. When followed properly, this document makes expectations clear and will also provide project milestones that will make it simple to determine progress.

Phases of waterfall project management  

The specific waterfall phases vary somewhat from source to source, but they generally include:

1. Gathering requirements and documentation

In this initial stage, you should gather comprehensive information about what the project requires. You can gather this information in a variety of ways, from interviews to questionnaires to interactive brainstorms. By the end of this phase, the project requirements should be clear, and you should have a requirements document that has been distributed to your team.

2. System design

Using the established requirements, your team designs the system that will be used to create the end product. No coding takes place during this phase, but the team establishes specs such as programming language or hardware requirements.

3. Implementation

Coding takes place in this phase. Developers take information from the previous stage and create a functional product. Typically, developers implement code in small pieces, which are integrated at the end of this phase or the beginning of the next.

4. Testing

Once all coding is done, testing of the product can begin. Testers methodically find and report any problems. If serious issues arise, your project may need to return to phase one for reevaluation.

5. Delivery/deployment

In this phase, the product is complete, and your team submits the deliverables to be deployed or released.

6. Maintenance

The product has been delivered to the client and is being used. As issues arise, your team may need to create patches and updates to address the issues. Again, major issues may necessitate a return to phase one.

Advantages of the waterfall model

Waterfall relies on teams following a sequence of steps and never moving forward until the previous phase has been completed. This structure is suited to smaller projects with deliverables that are easy to define from the start.

Ben Aston from The Digital Project Manager explains, "Waterfall is generally regarded with some disdain as an inefficient and passé traditional project management approach. But waterfall can be a useful and predictable approach if requirements are fixed, well documented, and clear, if the technology is understood and mature, if the project is short, and if there’s no additional value gained from 'going Agile.' A waterfall approach can actually provide more predictable end result for budget, timeline, and scope."

Here’s an in-depth look at what the waterfall methodology does best.

1. Uses clear structure

Compared to other methodologies, waterfall focuses most on a clear, defined set of steps, and its structure is simple. Each project goes through the six phases outlined above. If there are roadblocks to completion, they’re brought to light right away. Half-finished projects are less likely to get pushed aside, leaving teams with a more complete, polished project in the end.

2. Determines the end goal early

One of the defining aspects of waterfall is committing to an end product, goal, or deliverable at the beginning, and teams avoid deviating from that commitment. For small projects where goals are clear, the waterfall model is beneficial for making your team aware of the overall goal from the start, with less potential for getting lost in the details as the project moves forward.

If your team has a concrete goal with a clear end date, waterfall will eliminate the risk of getting bogged down as you work toward that goal.

3. Transfers information well

Waterfall’s approach is highly methodical, so it should come as no surprise that the methodology emphasizes a clean transfer of information. Whether you’re passing projects off at each step or experiencing unexpected personnel changes, waterfall prioritizes accessible information so new additions to the team can get up to speed quickly.

You can maximize your benefits from this characteristic of waterfall by documenting processes so that each team member knows what has already been completed for a project when it gets to them.

Disadvantages of the waterfall model

So, what is the downside of using the traditional waterfall approach?

Waterfall is a respected methodology, but it has faced criticism for being an outdated model. The limitations of waterfall become more apparent depending on the size, type, and goals of a project. Consider these limitations to assess whether waterfall is truly a fit for your team.

1. Makes changes difficult

One of the advantages of the waterfall model is also one of its drawbacks: Waterfall is based entirely on following a set of steps that keep teams always moving forward. The methodology, in its traditional form, leaves almost no room for unexpected changes or revisions. 

So, if your team has loyally followed the steps of waterfall nearly to the end of the project, but then faces an unplanned roadblock that necessitates a change in scope or goals, pivoting won’t be easy. A sudden change to the parameters of the project could render much of the work you’ve carried out up to that point useless, which can throw off the entire timeline.

2. Excludes the client and/or end user

Another limitation of the waterfall model is that as an internal process, waterfall focuses very little on the end user or client involved with a project. The methodology’s main purpose has always been to help internal teams move more efficiently through the phases of a project, which can work well in certain industries. However, clients often want to be involved during a project, adding opinions and clarifying what they want as the project moves forward.

If your projects have clear, unchanging goals from the beginning and you aren’t responsible for updating end users or clients through the development process, then waterfall will probably work well for your team. In other cases, consider an Agile framework to better anticipate change and keep stakeholders informed through the life of the project. By involving stakeholders, you lower the risk of late requests for change throwing off your project deadlines.

3. Delays testing until after completion

Testing is one of the biggest downsides of the using the traditional waterfall approach. Saving the testing phase until the last half of a project is risky, but waterfall insists that teams wait until step four out of six to test their products. At this point, the project has likely taken considerable time to complete, so large revisions could cause significant delays.

The Agile methodology was created in direct response to this principle of waterfall. Critics of waterfall felt that there was too much room for problems to remain unnoticed until the project neared completion, which left large, costly changes as the only solution. If you feel that frequent testing would serve your team better, implement testing at the end of every project stage so that you don’t move forward until you know things are working. Or consider a different project management methodology that encourages reflection and revision throughout the process.

Navigating waterfall model advantages and disadvantages

The waterfall methodology has had critics and supporters since its inception, but it remains relevant today even as other methodologies have evolved to account for many of its flaws. If your team is small and your projects are consistent and predictable, then waterfall could provide the ideal framework for keeping your team organized and on track.

If not, don’t be afraid to customize a project management methodology to make it right for you. With Lucid, you have free rein to create a structure that will work best for your team and its unique needs. Visualize your waterfall process or any methodology you choose by using Lucid.