What was Waterfall?

Despite research and publications by ourselves and many others there still sems to be some widespread confusion over what Waterfall was.  This post is in the words of the people who developed the concept: The term and the waterfall diagram come from this paper published in 1976:

The full paper can be downloaded from: https://mosaicprojects.com.au/PMKI-ZSY-010.php#Agile

Bell and Thayer’s paper was focused on problems with developing requirements for software projects.

Their conclusion was that defining requirements was a common problem regardless of project size, and to propose a solution:

MIL-STD-490 is for developing and maintaining specifications:

MIL-STD-483 was for Configuration Management Practices for Systems, Equipment, Munitions, and Computer Programs.

Figure 1 from Bell and Thayer’s paper is:

This flow was accepted by the USA DoD and incorporated into DOD-STD-2167A (1988) Defense System Software Development, which updated the DoD requirements for the development of mission critical software to require a sequential approach (waterfall by default).

Royce

Bell and Thayer clearly did not understand Royce’s 1970 paper (and neither appears to have had any software development experience).  Royce’s complete model is:

Royce’s paper did include a diagram similar to Bell and Thayer’s Figure 1:

BUT when you read his comment on the model ‘the implementation described above invites failure’, it is clear the rest of the paper describes how to avoid failure by implementing iterative and incremental development processes.  The full Royce paper can be downloaded from: https://mosaicprojects.com.au/PMKI-ZSY-010.php#Agile

Conclusions, Myths, and Discussions:

Facts:

Waterfall is a software development methodology based on progressively expanding requirements documentation in a single pass.

Royce did not advocate waterfall. His full paper advocates iterative development and feedback loops.

The USA DoD from the late 1970s through to the present-day use Earned Value Management as their project management methodology for all projects, including software development projects (not waterfall). For more on the history of EVM see: https://mosaicprojects.com.au/PMKI-ZSY-020.php#EVM

Discussion:

Using a waterfall approach to develop software will result in a different management approach to producing the output from the project, compared to an iterative approach to the same development.  This is no different to the differences in management needed between a decision to use precast concrete for a building instead of in situ concrete.  All aspects of the project management will adapt to reflect the different way of working.

However, precast concrete is not a project management methodology, and neither is waterfall.  

Since the Industrial Revolution traditional engineering projects have needed a complete design before construction could start. Oil refineries and other process plants need the route of every pipe determined, with changes in level, bends, etc., defined to allow flow and pressure to be calculated and the pipe and pumps sized correctly.  

These design and management processes predate the Bell and Thayer paper by a century or more and whilst both predictive and sequential, they are definitely not ‘waterfall’.

As discussed in other posts, the term waterfall was not applied to project management methods until the 2000s, when the term was used by various agile advocates to differentiate their form of agile software development from the failed waterfall approach to software development.  From the perspective of this paper, the big difference between agile and waterfall is many versions of agile do blend how the work is managed with how the software is developed.  Waterfall does not.

The migration of the term ‘waterfall’ from a software development process to a derogatory term for all traditional projects using a predictive, sequential approach to design then construction seems to have been a function of institutions, particularly PMI, who could not differentiate between software development and other types of projects. Fortunately, this trend has been killed off. In PMI’s more current publications waterfall has been returned to its proper place as a software development method, and other terms are being used for the many and various non-agile ways of managing projects (see: Waterfall is Dead). For all pervious posts on this subject see: https://mosaicprojects.com.au/PMKI-ZSY-010.php#Agile

The next phase of development will be dragging traditional project management into the 21^st century with the recognition that agility (not Agile) is an important aspect of managing any project. This is one of the objectives of Project Controls 3.0: https://mosaicprojects.com.au/PC-3-00-Overview.php#PC-3-Overview