The idea of project management has existed since the need for collaboration existed — which is a very long time. To encourage survival, leaders have always stepped up, whether ruling over large nations or smaller gatherings. Then products were created and grand structures were built — each of these “projects” required some form of structure, delegation, and management in order to reach accomplishment. In other words, project management as a concept is just as old as humanity itself.
However, project management as it’s now understood and practiced didn’t see its beginning until the 20th century. Gantt charts, which are still popular today in some project management methodologies (like Waterfall), were developed in the early 1900s, for instance. Throughout the remainder of the 1900s, various project management methodologies came and went.
One of these methodologies, which is still so frequently discussed today, is the Waterfall approach to project management.
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:
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 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.
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.
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.
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.
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. Today there are many software testing services dedicated to this step of the process.
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 product 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?
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.
With the wide availability of project management software and the advancing technology of these programs, 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 program a team chooses to manage their Gantt charts, 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.
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 Google Drive, Evernote, and Dropbox, for instance, 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.