When starting new projects, companies face a decision of choosing which development methodology to use and one methodology that has historically been very popular is the Waterfall methodology. Development methodologies are simply a way to organize the workflow of product (usually software) development and there are pros and cons to each methodology. In this post, we’ll discuss the strengths and weaknesses of one specific methodology: Waterfall.

The Waterfall approach is a sequenced method of events that usually follow:

1. Idea
2. Analysis
3. Design
4. Development
5. Test
6. Final Product

A team will first come up with an idea which they will analyze in order to determine and prioritize business needs and requirements. Next, they focus on the design phase where the business needs are translated into technical requirements (i.e. decisions about which tech stack to use). Once all of these business / technical needs are finalized, the team can begin the code development. After development, the team begins code, systems, and user acceptance testing in order to fix any issues before they deliver the final product.

Waterfall Pros:

• The waterfall method requires extremely meticulous documentation which means there will be good references for future products. In addition, if anyone suddenly changes / leaves the development team, the strong documentation will allow someone else to pick it up quickly, which minimizes impact to product deadlines
• Both the development team and customers spend time early in the lifecycle agreeing on what will be delivered which allows everyone to have a better idea of what to expect in terms of size, cost, and timeline for the product.
• Since the design aspect is completed fairly early on, the development team can work on multiple components in parallel
• There is tangible output at the end of every single stage which means that all stakeholders can feel more comfortable seeing progress being made

Waterfall Cons:

• The process of gathering requirements from customers is a really tough process from the get go because customers may not necessarily have a good sense of the final product even if you give them wireframes and mockups. Because of this, there is a good chance that the customer will be unhappy with the final product since they can’t see what is being delivered until it is almost finished
• The waterfall plan doesn’t take into account users’ evolving needs so if the team discovers that the user demands different changes later in the process, it is very difficult to go back and start from the beginning
• Feedback and testing are deferred until very late in the development cycle so bugs can severely impact how other code was written if discovered late

Ideally, your team should be using the waterfall methodology if there is a very clear picture of what the final product will be and if you know that your users won’t have changing needs once the project has begun.

In our next post, we discuss the Agile methodology, which was developed to address many of the disadvantages of the waterfall method.

Interested in discussing the Waterfall methodology with other product managers? Meet and chat with product leaders around the world in our PMHQ Community!