What Is Waterfall Project Management?
Waterfall project management is an approach to deliver projects in a linear and sequential order. The process starts with planning, followed by analyzing, designing, implementing and testing and finally deployment.
This type of structure is often used for projects that require a well-defined plan, have specific deliverables, and require the completion of tasks in a specific order. The advantage of this approach is that it allows for a clear sense of goals, tasks and timeline.
Waterfall project management is useful because it is simple and offers a clear path for project teams to follow with an easy to understand timeline. It also provides tangible deliverables that can be objectively measured and tracked, allowing for tighter control of the project. Additionally, the rigorous nature of the waterfall approach supports a smooth progression from concept to implementation and results in a successful project completion.
Waterfall project management is also a method that can be integrated into project management software for easy application. Each stage has its own set of tasks that need to be completed in order for the project to progress to the next step. Each following stage is only begun once the prior stage has been completed – this is a very easy structure to recreate in project management software such as Hive.
The Waterfall Method’s Grand Entrance
Waterfall project management saw its beginning as a method for managing construction projects and manufacturing processes, which greatly explains its rigid nature and dependence on linear phases.
There is some discrepancy about when the concept of Waterfall methodology actually began (some say the 1950s, while others emphasize the 60s). 1970, however, saw Waterfall’s first definitive application to the field of software development when Dr. Winston Royce published a paper called “Managing the Development of Large Software Systems.” In this paper, Royce still never used the word “waterfall.” Instead, it was the diagram structure he used which elicited the image of a waterfall as project phases were cataloged from the top left of the page to the lower right, with arrows flowing from one phase to the next.
It’s speculated that this methodology was first termed with the name “Waterfall” in a later paper published in 1976, where authors T. E. Bell and T. A. Thayer asserted that new techniques were necessary in the world of software engineering in order to more clearly delineate requirements.
With the release of the Agile Manifesto in 2001, Waterfall project management stepped out of the spotlight, but it’s far from dead! Today, Waterfall is still used (albeit with some modifications from its original form), and there are many project management experts who see Waterfall merging with Agile to create a bright future.
But what exactly is Waterfall project management?
The Ideas Behind Waterfall Project Management
Unlike Agile frameworks, the Waterfall approach to project management is more rigid and methodical in the way it organizes a project’s steps from start to finish. It utilizes a linear model of time to break down a project into multiple parts. These parts are then completed sequentially. Visually, these distinct stages from a project’s start to finish can be viewed as water trickling downwards—the phases flow like a waterfall from top to bottom.
Just like a waterfall’s flow can’t be reversed once it begins its downward journey, there is little room for midway adjustments or changes once a series of goals is laid out at the beginning of a project. Instead, Waterfall project management relies on creating a sequential plan, then carrying out the stages of this plan until the project reaches completion.
It’s this aspect of Waterfall project management that is often seen as the largest setback associated with the method, but that’s not to say that Waterfall project management is bad. After all, an unviable methodology wouldn’t still be around after more than 50 years!
Deeper into the Waterfall
Diving a little deeper into the details of Waterfall methodology means a more thorough understanding of the phases involved. Each phase exists as a discrete aspect of the project, and one phase must be completed before the next can begin.
The phases as originally recorded by Royce are:
- Requirements
The initial phase of the Waterfall methodology emphasizes the creation of a requirements list. These requirements are based upon the guidelines set forth by the client and project stakeholders and should be sufficient to fulfill the identified purpose of the product. The requirements are recorded in a way that can serve as a guideline for future phases of the company’s new product development process.
- Analysis
While Analysis and Requirements are sometimes combined into a single step, others consider them to be separate entities. While the Requirements phase focuses on identifying each aspect necessary for the final product, the Analysis phase allows an opportunity for everyone involved in the production (as well as stakeholders or product owners) to fully understand how these requirements can be accomplished.
- Design
Creation of the project itself begins with this step, when particulars such as coding language and other high-level details are agreed upon. The pillars of design determined in this phase will serve as the framework upon which the remainder of the project is built.
- Coding
One might say that this phase fills out the details necessary to create a final product from the foundation laid in the “Design” phase. In software development, this is the act of creating the software itself, based upon the requirements and significant guidelines decided upon in previous phases.
- Testing
Once the software has been built, its completed form is tested. This confirms that requirements have been met, and ample time is dedicated to locating and fixing any bugs in the existing program. During this phase, the product is typically tested by a variety of testers in order to ensure the most thorough analysis of the finished product. For example, software load-testing determines the performance of the software under specific conditions, which can help you understand its sustainability and scalability.
Today there are many software testing services dedicated to this step of the process, including API security testing, A/B testing and more.
- Operations
The final phase of Royce’s original Waterfall model, “Operations” is defined by the ongoing installation and maintenance of the developed system. In other words, the final result of company’s product development process is delivered and implemented within the real world, and thus the waterfall reaches its end.
These phases were developed, of course, specifically for the development of software. However, their general principles can be applied to a variety of other projects as well. Still, many would argue that the rigid nature of Waterfall still remains best suited for software development, though that shouldn’t deter others from adapting and implementing the process for their own projects with distinct phases and goals.
Modifying a Waterfall Process
As previously mentioned, significant variants of the Waterfall process may be implemented despite the rigid nature of its setup. Even Royce himself developed what he called a “final model” which contained substantial deviations from the original model outlined above.
In his 1970 paper (yes, the one which introduced Waterfall as an official methodology for the development of software), Royce admitted the potential for failure due to the testing phase’s placement at the end of this linear line. The inability to backtrack meant that, if testing failed at the end of the line, massive overhauls rather than small adjustments would be necessary in order to resolve issues discovered via testing.
Royce then proposed some modifications to his original model which emphasized more interaction between the various phases with opportunities for feedback along the way. For example, feedback between testing and design became crucial to his final model, as did feedback from design back to requirements.
Others put their own spin on Royce’s Waterfall model. Peter DeGrace, for instance, introduced the Sashimi model. Visually, this model appears the same as the Waterfall model but with one notable exception—the phases overlap one another instead of existing as unique entities joined only by progressive arrows.
Is Waterfall Project Management Still Used Today?
Absolutely!
Despite the inherent risks associated with a linear model like this one, project managers everywhere remain fond of the Waterfall project management model for certain projects. Some utilize the Waterfall methodology in its original form while others prefer one of its modified counterparts, but the basic tenets of Waterfall remain the same.
While Waterfall may not be as popular as it once was, numerous project managers prefer the Waterfall methodology to help their teams accomplish goals and deliver products. Waterfall may be considered obsolete, but it still has its place amongst projects with particular requirements and characteristics.
For example, the Waterfall project management methodology is particularly suitable for projects:
- With specifications and requirements laid out clearly by the client
- Whose guidelines will be unchanging throughout the product’s development
- With strict deadlines and linear goals
- Created by teams who can benefit from a simple development structure and schedule
- Whose technologies have been utilized before and are familiar to the development team
Waterfall also places an emphasis on documentation that makes it stand out as a methodology advantageous for teams that may see project handover or employee turnover during the time of a project’s development. Strict documentation and a simplified development structure make it easy for new entities to pick up the project and carry it to completion.
The Waterfall Project Management Toolshed
Like any other project management methodology, developers have created numerous technologies to make the implementation of Waterfall easier within groups. These programs utilize certain features in order to make the visualization and organization of Waterfall more effective within teams. For example, Gantt charts, one of the first iterations of modern project management, serve as excellent visual tools for the implementation of Waterfall.
Gantt Charts
With the wide availability of online project management solutions and the advancing technology of these platforms, Gantt charts have become even more useful. Now, they are dynamic, customizable, collaborative, and boast an incredible user experience for any team utilizing the Waterfall methodology to complete a project.
A few of these programs include:
For teams relying on solutions such as Google Drive or Office365, Gantt charts can also be created in Google Sheets or Microsoft’s Excel.
Whichever Gantt chart program a team chooses to manage projects, it is arguable that this will be the core of the Waterfall project management process. Not only do Gantt charts appear visually just like the original Waterfall model proposed by Royce, but both axes of these charts benefit teams by delineating a list of tasks to complete as well as an appropriate timeline in which to complete them.
Documentation
Because of Waterfall’s reliance on detailed and consistent documentation, project managers frequently choose between a number of collaborative, cloud-based solutions to keep this documentation accessible and easily modifiable by all members of a project team at once.
Mainstream services like Evernote, Google Drive and Dropbox make it easy to collate project requirements and other essential documentation.
Other programs more specific to the sphere of project management include:
These are only a few of the available products, however, and the combination of Waterfall tools that’s right for any particular team will largely depend on how that team and its project manager have chosen to adapt the Waterfall methodology to their own process.
Does Waterfall Have a Future?
Despite Waterfall’s continued relevance decades after its inception, some project managers may wonder just how long Waterfall project management can remain viable when Agile has dominated the project management sphere since the early 2000s.
While there’s no doubt that Waterfall has a future, experts like Alex Rodov and Jordi Teixidó predict that the evolution of project management will yield some kind of hybrid between the Waterfall and Agile methodologies. In fact, one might even say that Royce began this process himself when he first proposed the Waterfall methodology in 1970. In his own paper, he recognized the risks associated with a linear model that lacked room for incremental testing or feedback.
In 2016, Rodov and Teixidó published a paper outlining their own recommendations for how these approaches might be successfully blended into a single, dominant methodology. They point out that Waterfall methods have often been used incorrectly over time and that it is these poor implementations of Waterfall which have dominated the way experts compare Waterfall to Agile.
In their proposal for a hybrid model, they suggest combining Agile’s user stories and the emphasis on requirements that is characteristic of Waterfall. They also encourage the use of Waterfall project management strategies to initially define a project’s scope. However, only time will tell if these predictions come to fruition or if the changing course of project management will surprise us all.
Have you utilized Waterfall methodologies throughout your career? Do you find it useful? Let us know in the comments below.
