Waterfall (predictive) model

The waterfall model, or aside of the software development environment commonly called predictive model, refers to a technical approach to plan and breakdown projects. Originally intended for software development, this method has been evolved and assimilated to different scenarios including distinctive styles of project management. Today’s definition of the waterfall model refers to linear sequential planning of steps or phases, but over time various adjustments, extension and further developments to the original model have been made. In the context of project management, it is often referred to as the predictive or planned approach because of the high level of detailed and advanced planning for the complete project scope.

History and Evolution of the Model

Originally designed to structure the increasing complexity in software development, the first definition of the different phases for the program production life cycle have been described in 1956 by Herbert D. Benington based on a hardware development approach . After publication of similar models, the first formal description for the waterfall model is based on Beningtons model and has been published by Winston W. Royce in 1970, which became popular as the main reference today. However, his interpretation formed the inclusion of feedback cycles compared to the first expression by Benington. In 1976, Thomas E. Bell and T. A. Thayer used the term “waterfall” for the first time when referring to Royce paper. Later in 1983, Benington republished his paper and clarified that the phases were not intended to be used in a non-iterative or strict top-down fashion.

As described by Royce, there are inefficiencies in the later waterfall model, due to the lack of verification. Therefore, each step should refer to the previous one and verify their results. At that time the model was based on 7 phases: System requirements, software requirements, analysis, program design, coding, testing and operations . The fast-changing environment of software development and increasing complexity continuously evolved the model and the need for a more iterative behavior increased, which resulted in today’s adaptive and agile approaches. Today, different variations and extensions of the model can be found in literature. Some variations contain extensions to the original model such as cascades, in which not only a top-down direction is intended, also a bottom-up verification after each step is anticipated as described by Barry W. Boehm in 1988 . Therefore, applications of the original waterfall model in other areas than software development changed the model to the more generic stages of feasibility, design, build, test, deploy and close. The basic model used today for project planning contains 5 stages, while the model prevailed used in software development uses the 7-stage variant of the waterfall model.

The Model

Depending on the source, different variations of models with different phases can be found in literature. While the general model for project planning contains 5 stages, some variations contain additional steps connected to the planning phase at the beginning or specific maintenance phases at the end. The model primary used in project management contains 5 phases and is based on the four-step life cycle: development, realization, utilization and disposal. For each phase there are defined start and ending conditions as well as the output from previous phases is used in the subsequent phase. After each step, the progress gets documented. Furthermore, each phase is finalized with a stage-gate process to check if all requirements are met. Based on this process the following phase can only be started if the previous stage and their defined goals and criteria have been fulfilled. These generic phases are more to understand as guidelines instead of strict rules. The phases are:

1. Initiation Phase
   Often referred too or called as feasibility phase, definition phase or requirement gathering and analyzation. For practicality reasons these different activities often getting grouped in one phase. This phase particularly is related to the application in project management. During the first phase of a project the overall scope is getting defined. Information and knowledge is gathered, commination takes place to initiate the launch. This includes not only the state of start and end conditions, but also the budget and resources which can be used. Based in the given information an estimate about the project can be concluded. In this early phase of the project, it is still possible to terminate a project if the assessed data shows that is technically or economically feasible to realize. This evaluation can make use of different techniques and methods depending on the type of project.
2. Design Phase
   Also referred to as the planning, concept or requirements phase. In the design phase the project scope getting shaped. Concrete measures and definitions to the scope getting defined. Extensive research and comparisons take place to fully understand upfront what the designated final state must be. Specifications and characteristics are set to a high level of detail.
3. Build Phase
   The build phase can also be referred to as the action phase, implementation or execution phase in models with less steps. Generally, this is the stage to take the most part during a project. Execution of the project is started
4. Test Phase
   During the test or validation phase, the deliverables are getting proved against their intended use case. Outcomes and results getting monitored and the testing itself should be planned and controlled. This case can take up a relatively high amount of time, depending on the sensitivity of the project.
5. Deploy Phase
   This phase includes the installation and, in some projects, also the maintenance. This step is often grouped together with the following closure phase in which the project gets finalized and typically handed over to the customer. Implementation or integration of the project in the intended environment gets initiated. Partially some of these activities can also be done during the test phase before head.
6. Closure Phase
   This phase particularly is related to the application in project management. Full documentation and evaluation take place, teams getting released and the project is getting closed. Regardless of the used model, adjustments after this phase are not considered as part of the original project anymore, furthermore they are part of the operation, a follow up project or take place within the portfolio or program management.

Requirements

To be able to successfully apply and use the waterfall model for the planning in project management, the project must meet some basic criteria and requirements:

• The project must be planned predictively and exhaustive before the start. Changes during the problem are not intended and changes of the plan or problems will cause high cost or time overruns. Therefore, an early definition of requirements, performance measure and processes have to be defined defined.
• The project scope must have a robust and fixed definition of the start and final stage as well as a formulation of the goal. Furthermore, it should be categorized as project. The waterfall model is not intended to be used in continuous projects and is not practically to use in program or portfolio management.
• Intermediate steps have to be planned to a high level of detail. This includes budgeting and step by step planning in a linear manner.
• Projects planned with the waterfall model usually include a high level of governance by the centralized management team and expect non or less unpredictable changes during execution.

Variants

A common practice in projects with a more complex structure is to extend the waterfall model by cascades. In this model the linear top-down direction gets replaced by a single step iteration. In case a defect or problem occurs during one step or is detected during the stage-gate process, one step back to the next higher hierarchical phase can be done to correct the problem. It is not intended to go back more than one step. This allows a single iteration after passing one phase to adjust in case of deviations, align with updated data or correct in terms of mistakes. Therefore, the original linear structure and plan is maintained. But with ongoing progress the costs for eventual defects are increased drastically the later they are found and corrected. Royce stated already in his paper that his executions of the model are not meant to be strictly linear. Therefore, the application and the use of cascades must be evaluated and defined individual before a project. For example, to cascade back during a construction project where construction measures have been performed already does not make sense, whereas the use in manufacturing to update changed specification before the execution does make sense.

Application in Project Management

Some sources argue that the waterfall model should only be used in shorter projects. This has the advantage to reduce the expenditures spent for the planning only. But generally, the costs savings through thoughtful planning are significantly higher than the cost for the high level planning in more complex or bigger projects. This frontloading requires a high number of resources and precise estimates, but reliefs the later stages and execution costs. Especially in early phases a coordinated collaboration between different stakeholders of the project is necessary to establish a verified foundation to be used in the waterfall model. Therefore, the detailed planning benefits from the exchange of various involved stakeholder, even before the project started. Usually in big projects different teams can be assigned to different tasks, this brings the advantage to allocate the knowledge and expertise directly to specific phases, whereas all of them together getting guided by the aligned plan of the project management itself.

Examples

• Construction: Construction projects, regardless of the dimension usually follow a defined plan. It starts with the definition of the scope, for example the size of a house or bridge. Followed by the design where based on the requirements and within the budget the scope getting shaped to a concrete goal. In the next phase, either the procurement and preparation oder directly the execution takes place. Until during the deployment phase the project gets finalized and handed over. As given in the classic waterfall model, iterations or steps back are not intended as well as a strict linear progress along the plan. In reality, it is not possible to build the roof, before the foundation is set. Regarding the handling of problems and changes, it is important to detect and solve these as early as possible. In the works case scenario a project like this has to be aborted if for example defects or wrong design in crucial parts if a bridge been found after construction has started. This example show how important detailed planning as well as consequent stage gate processes are to find and eliminate possible issues before the current phase getting closed and the execution of the subsequent phase starts.
• Manufacturing: Engineering projects, take the design and construction of an airplane as example...
• Cooking receipts: follow a given order for a reason. When baking a cake the dough has to be made before the filling!

Advantages

Benefits by the use are mainly generated by elimination of inefficient practices in later phases of the project. The main advantages are shown below:

1. Clear definition and separation of stages. The use of the waterfall model establishes clear separation between the individual process steps. Not only by a categorization of processes and task, also verification by pre-defined start and entry conditions to finish and start a new phase. These transitions can also be seen as project milestones. Furthermore, the distinctive differentiation supports the precise estimation of costs and time in the beginning of the project. This procedure gives a good overview of the running task, since less processes and tasks must be executed at the same time or parallel. Also, overall progress if the project is visible and quality, even during the process, due to the clearly defined specification and criteria.
2. Synergies and cost efficiency through focus. Entirely and precise planned projects not only trigger overruns within boundaries of time and budget, furthermore they are more efficient due to throughfall planning. By execution on efficient resource planning running costs can be lower significant compared to a more adaptive approach. All these gathering and analyzing of information beforehand lead to more concrete estimates of costs and time. By approaching individual steps instead of the whole at one, lessons learned from each previous stage can be applied to the following phases. These characteristics, the use of milestones and precise planning in common tend to finish project more often within the boundaries of budget and time compared to agile management.
3. Simple: smaller, individual tasks within similar fields of work are easier to manage compared to large scale parallel practices. Less complexity led to higher rates of achieving the desired result in the first try. And smaller intermediate steps are easier to understand. Especially in industries and companies with strong hierarchies and classical approach tend to prefer to adopt the predictive approach compared to adaptive approaches.
4. High quality results that meet the project goals, even in sensitive project with w high risk of total loss: risk getting reduced to extensive research and information gathering before head. High amount of decision making and estimation about robustness of the project. This form of model result in detailed documentation about each step and includes robust testing in the testing phase. As ach phase gets specifics outputs therefore easy to review and assess success of the overall process. The extensive resources used for each phase lead to a high quality which with the use of the waterfall model is prioritized over speed and flexibility. Therefore, the use is recommended in non-urgent but highly sensitive projects.

Limitations

Beside the advantages gained through the simplicity of the model, it comes along some limitations regarding the usability and capabilities of the method:

1. The waterfall model generally is inflexible ion terms of changes after the initiation and planning of the project, however there are change control process who can be implied and integrated into the process to have control in terms of changes. When changes either through adjustments of the original plan or through found problems should be made, its often hard to implement in the running process. In terms of change the different options and outcomes must be assessed carefully to decide about ongoing and trying to improve later or go back during the process and basically re-start from the beginning under the updated circumstance.
2. Occurring problems often getting detected relatively late in the project. Due to a lack of testing or validating of solution in the early stages problems failures can happen or weaknesses of the concept are not getting properly detected and therefore being detected relatively late in progress. Furthermore, other problems, usually getting detected in the testing or validation phase, but this phase comes in a late stage of the project, when most conceptualization and execution has taken place already. This can usually be avoided by proper planning and evaluation of information, but in terms of conceptual or first to be projects there’s often a lack of information from the beginning. In situations like this it is to consider if the waterfall model is the best choice under the given circumstances.

Both problems, often in combination, the occurrence of a problem at a late stage of the project can lead to severe cost and time overruns.

3. There’s generally low stakeholder engagement, beside the initiation and planning stage in the early phases. Also end customers have less possibilities for input and feedback during the project. Feedback usually is only gained at the end in the post project review.
4. The waterfall model is generally not suitable for object-oriented projects which have high uncertainty, risk or incomplete and verified knowledge. Therefore, it is indeed suitable for complex projects, as long it is feasible to create a detailed project plan.

Connections

Especially in the field of software development, the common practice has been evolved away from the classic predictive approach. These changes happened mainly due to uncertainty in planning. Generally, but not exclusively to software development a final stage or status of finalization is hard to define before or at the beginning of a project. But also, the increased complexity in more connected and complex programming environments and higher number of participants within teams pushed these changes. Outgoing from the waterfall model, extension like the application of iterative circles or backsteps as the cascade model evolved. In terms of predictive planning the V-model is widely used today. Followed by the spiral model by Boehm and finally agile and scrum methods have become the new standard in software development but are also used in wide parts of project management. Therefore, it is to mention that this method can be, like the waterfall model itself, applied to various kinds of scenarios and are not limited to software development alone, but depending on the individual assessment of requirements, knowledge and information of a project is it to consider if the higher expenditure is generating additional value or is generally required to achieve the same results compared to the simpler predictive methodology. Another approach is the V-model, especially in software development.

Annotated Bibliography

Project Management Institute. (2021). The Standard for Project Management and a Guide to the Project Management Body of Knowledge (PMBOK Guide).