Imagine you are hiking through a tropical rainforest when off in the distance you hear the sound of crashing water. You follow the sound and before long, stumble into a clearing with a crystal clear pond fed by a cascading wall of water sliding down the face of a cliff. Take a moment and think through what you are seeing. The water, much like a traditional project, comes flying over the edge of a cliff at breakneck speeds. It won’t slow down until it hits the pool below, or until the individual water droplets are torn apart by aerodynamic force turning them into the mist that you see floating off in every direction. Projects seem to have the same options of fate. Either they are completed successfully or they are torn apart by bureaucracy, quality issues, delays, and shifting priorities. For the lucky droplets that do make it to the bottom they must fall from rock to rock as they wind their way down the cliffs face. Similarly, traditional projects are passed from phase to phase, team to team, or department to department as they go through a predefined process that is designed (much like gravity) to be a one way trip. It is because of these similarities that traditional project management has been given the name “Waterfall”.


So, what is Waterfall Project Management?

Imagine a Waterfall cascading down a cliff


Now turn that Waterfall into a project. Each rock is replaced by a step in a process, and the water is replaced by a stream of projects all moving in the same direction.

Waterfall Project Process

The process generally starts with a planning phase where every minute detail is hammered out and written down. This includes specification documents that outline all business rules along with detailed financial projections. This comprehensive documentation is one of the major differentiators for this methodology. When that is done, the project is either handed down to the next phase, or it is added to a queue and waits for the availability of the next phase. Phase by phase each person, team, or department pics up the project, fulfills their expected duties according to the original specifications and budget, and then passes it on to the next phase. When it is all done the expectation is that it will have produced something of value for the customer. Be it a building, or a software project, the Waterfall process works perfectly… in a perfect world… with perfect people, where all projects go according to plan.

Proponents of Waterfall say that the process saves significant time by identifying and addressing issues upfront. Additionally, there is something to be said for the reality that complete documentation ensures continuity when a team has turnover. Opponents of the method however complain that too much time is spent figuring things out upfront without the feedback of the team responsible for building it. They claim that this delays delivery, and reduces team member buy-in.

The largest criticism of this methodology however is historical proof. The technology industry adopted Waterfall thinking early on and subsequently became notorious for project delays and budget overruns. Many believe that this is because of a flawed assumption that assigning a manufacturing approach to a dynamic engineering discipline, which requires creativity and flexibility, could work. 

Regardless of the prevailing opinions, the main issue with this approach is the lack of a defined process for moving a project backwards up the Waterfall. Generally speaking any change requires the project to be rerouted back to the top of the falls to start over again with updated specification and budget documents.

To alleviate this, organizations have implemented change management processes so that changes during the process can move through a separate Waterfall process in parallel to the larger project, thus avoiding the need for the large project to start from the top of the falls again.

The other well known avoidance tactic used to limit rework is the idea of phase gates. With a traditional phase gate, someone has to sign off that all steps in a phase have been completed and that they match the specifications before the project can progress into the next phase.


Example 1: Building a house

Building a house using the Waterfall Methodology could look something like this:

  • Create a budget & schedule
    • Design the blueprint
      • Lay the foundation
        • Build the frame
          • Install electrical & plumbing
            • Finish the inside
              • Finish outside
                • Landscaping
                  • Sell the house

Each step of course would be comprised of dozens of smaller steps, each with their own timeline and budget. In order to build things this way it is critical to do an in-depth check before progressing to the next phase. With the Waterfall method, going back to a previous stage is expensive and it threatens other projects timelines and budgets.

Example 2: Building a mobile app

Building a mobile app using the Waterfall Methodology could look something like this.

  •  Create a budget & schedule
    • Create functional requirements
      • Design a wireframe
        • Design the data layer
          • Develop the app
            • Launch the app

Note that verification and testing are possible, but they must be baked into the phase they are testing. For instance, user testing the wireframe would have to be done before it leaves the “Design a wireframe” stage. If it gets into the development phase and then needs updated designs you would have to break the flow of the Waterfall to send it back to design. 

Example 3: Building a business

Building a business using the Waterfall Methodology could look something like this.

  •  Create a budget & schedule
    • Create a business plan
      • Solidify product offering
        • Secure distribution channels
          • Ramp up production of product
            • Kick off marketing efforts
              • Launch Business

Starting a business is a great example of a project where you are not traditionally seeking to establish a consistent flow of similar projects back to back. In these cases it is less impactful to take a step back to an earlier phase, but that is against the concept of the Waterfall because it is time consuming, and thus costly.


Waterfall project management is a much needed discipline in some industries where repetition is possible and a mature technology is fully understood and thus predictable. Take a residential builder for example. They understand the technology available for building a home and can pre plan and order all materials in bulk for an entire neighborhood of predefined floor plans. Compare that to the technology industry though, where an engineer is never asked to build the same application twice and is faced with updated platforms and new code bases every year. This new type of rapidly changing environment present’s new challenges that the traditional Waterfall method may not be equipped to handle. It is because of this reality that a new methodology has arisen to compete for dominance in the Project Management world. The new concept is called Agile Project Management. To read more about this new methodology check out this article: What is Agile Project Management? For some historical context around the origins of project management and where Waterfall Project Management came from, check out this article: The History of Project Management

Shout out to Vexels for the awesome header vector art!