View source for Waterfall (predictive) model

''Created by Felix Hagen, March 2022.''
The waterfall model, or aside of the software development environment commonly called predictive model, refers to a technical approach to plan and breakdown projects<ref name="PMBOK"> Project Management Institute. (2021). The Standard for Project Management and a Guide to the Project Management Body of Knowledge (PMBOK Guide). Project Management Institute, Incorporated. </ref>. 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<ref name="PMBOK"> Project Management Institute. (2021). The Standard for Project Management and a Guide to the Project Management Body of Knowledge (PMBOK Guide). Project Management Institute, Incorporated. </ref>.

==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 has been described in 1956 by Herbert D. Benington based on a hardware development approach <ref name="Benington"> Benington, H. D. (1983). Production of Large Computer Programs. IEEE Annals of the History of Computing, 5(4), 350–361. https://doi.org/10.1109/mahc.1983.10102. </ref>. 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<ref name="Royce"> Royce, W. W. (1987, March). Managing the development of large software systems: concepts and techniques. In Proceedings of the 9th international conference on Software Engineering (pp. 328-338). </ref>. 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<ref name="Bell"> Bell, T. E., & Thayer, T. A. (1976, October). Software requirements: Are they really a problem?. In Proceedings of the 2nd international conference on Software engineering (pp. 61-68). </ref>. 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 only<ref name="History"> Kneuper, R. (2017). Sixty Years of Software Development Life Cycle Models. IEEE Annals of the History of Computing, 39(3), 41–54. https://doi.org/10.1109/mahc.2017.3481346. </ref>. 


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 seven phases: System requirements, software requirements, analysis, program design, coding, testing and operations <ref name="Royce"> Royce, W. W. (1987, March). Managing the development of large software systems: concepts and techniques. In Proceedings of the 9th international conference on Software Engineering (pp. 328-338). </ref>. 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. 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 <ref name="Boehm"> Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5), 61–72. https://doi.org/10.1109/2.59. </ref>. 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<ref name="PMBOK"> Project Management Institute. (2021). The Standard for Project Management and a Guide to the Project Management Body of Knowledge (PMBOK Guide). Project Management Institute, Incorporated. </ref>. The basic model used today for project planning contains five stages, while the model prevailed used in software development uses the seven stage variant of the waterfall model<ref name="ISO"> International Organization for Standardization. (2020). Project, program and portfolio management - Guidance on project management. (ISO 21502:2020). </ref><ref name="SDLC">Ruparelia, N. B. (2010). Software development lifecycle models. ACM SIGSOFT Software Engineering Notes, 35(3), 8–13. https://doi.org/10.1145/1764810.1764814.</ref>.

==The Model==
Today, different variations and extensions of the model with different phases can be found in literature. While the general model for project planning contains six stages, some variations contain additional steps which are connected to the planning phase at the beginning or specific maintenance phases at the end<ref name="ISO"></ref>.
The model primary used in project management contains six phases and is based on the four-step life cycle: development, realization, utilization and disposal<ref name="Troxler"> Züst, R. & Troxler, P. (2006). No More Muddling Through. Springer Publishing.</ref>. Each phase is an independent set of tasks, and each completed phase initiates the next one. For each phase there are defined start and ending conditions as well as the output from previous phases is used in the subsequent phases. 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:
[[File:Leeres Diagramm-2.png|550px|thumb|'''Figure 1''' Waterfall model. Own figure based on <ref name="PMBOK"></ref>]]
#'''Initiation Phase''' <br /> Often referred to or named feasibility phase, definition phase or requirements gathering and analysis. For practicality reasons these different naming activities often getting grouped into one phase. During the first phase of a project the overall scope is getting defined. Key values and risks are identified. Information and knowledge are gathered, communication takes place to initiate launch activities. This includes the definition of the start and end conditions, but also the planning and allocation of budget and resources for the complete project lifespan. Based on the given information, estimates about the project and feasible solutions 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 not feasible to realize. This evaluation can make use of different techniques and methods like MCDA, CBA, FRA and more, depending on the type of project.
#'''Design Phase''' <br /> Also referred to as planning or concept phase. In the design phase the project scope is getting shaped. Concrete measures and definitions to the scope are defined. Extensive research and comparison takes place to fully understand upfront what the designated final state must be. Specifications and characteristics are set to a high level of detail. Execution plans and procurement actions are prepared. 
#'''Build Phase''' <br /> The build phase can also be referred to as the action phase, implementation or execution phase. Generally, this is the stage to take up the longest to execute during a project. Execution of the project is started. 
#'''Test Phase'''<br /> 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 phase can also take up a relatively high amount of time, depending on the sensitivity of the project. 
#'''Deploy Phase''' <br /> 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. 
#'''Close Phase''' <br /> This phase particularly is related to the application in project management, in some models these activities are not considered as independent phase and grouped with the deployment. Full documentation and evaluation takes 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===
[[File:Leeres Diagramm-3.png|425px|thumb|'''Figure 2''' Cascades. Own figure based on <ref name="Royce"></ref>]]
To be able to successfully apply and use the waterfall model for the application 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, definition of requirements, performance measure and processes must be possible at the beginning of the project<ref name="Thesing"></ref>. 
*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<ref name="Project">Weaver, P. (2010). Understanding Programs and Projects—Oh, There's a Difference! Paper presented at PMI® Global Congress 2010—Asia Pacific, Melbourne, Victoria, Australia. Newtown Square, PA: Project Management Institute.</ref>. The waterfall model is not intended to be used in continuous projects and it 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<ref name="PMBOK"></ref>.

===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<ref name="SDLC"></ref>. 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<ref name="Royce"></ref>. Therefore, the application and the use of cascades must be evaluated and defined individual before a project starts. 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 specifications before the execution does make sense.

==Application in Project Management==
Beside the general requirements, additional matters must be considered. Some sources argue that the waterfall model should only be used in short and simple projects. This has the advantage to reduce the expenditures to be spend for the planning. But generally, the costs savings through thoughtful planning are significantly higher than the costs due 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 define a concrete goal. In the next phase, either the procurement and preparation or directly the execution takes place. 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 and the project should follow a strict linear progress along the plan. It is not possible to start with the roof, before the foundation and other floors are build. Regarding the handling of problems and changes, it is important to detect and solve these as early as possible. In the worst-case scenario, a project like this has to be aborted if for example defects or wrong design in crucial parts of a bridge is found after construction has started. This example shows 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: Due to the prolonged life cycle of an aircraft, often more then 30 years, it is important to future proof it as a product. But at the same time, the time span between the iteration of the design and construction of the aircraft, techniques, material usage and concepts change. Additionally, an aircraft is a very sensitive product due to its usage, which also prolongs the test phase drastically. To be able to construct an aircraft, but also to keep the costs as low as possible, try and error is not an option here, most of the design work and planning must be done before viable actions can take place. This includes the integrated usage of already developed parts and designs, but also the innovations and updates for the remaining features of the previous generation including the uncertainty they come with. In this specific case, indeed adjustments can be made if detected in the test phase and this will have significant impacts and trigger delays, but other than that the project will be executed in precisely planned manner. In this example, but also in other projects handling sensitive data, a failure is not accepted, and the risk must be minimized through excessive testing.
*Cooking receipts: Receipt follow a given order for a reason. When baking a cake, the dough must be made before the filling!

==Advantages==
Benefits by the use are mainly realized through elimination of inefficient practices in later phases of the project. The main advantages are shown below: 
[[File:Correlation.png|550px|thumb|'''Figure 3''' Correlation of information and costs. Own figure based on <ref name="PMBOK"></ref><ref name="Troxler"></ref>]]
#'''Clear definition and separation of stages.''' The use of the waterfall model establishes clear separation between the individual process steps. Not only by categorization of processes and tasks, also verification through pre-defined start and entry conditions to begin and end a new phase. These transitions can also be seen as project milestones. Furthermore, the distinctive differentiation supports the precise estimation of costs and time consumption in the beginning of the project. This procedure gives a good overview about the running tasks, since less processes and tasks must be executed at the same time or parallel. Also, overall progress of the project is visible and quality, even during the process, due to the clearly defined specification and criteria is measurable<ref name="Thesing">Thesing, T., Feldmann, C. & Burchardt, M. (2021). Agile versus Waterfall Project Management: Decision Model for Selecting the Appropriate Approach to a Project. Procedia Computer Science, 181, 746–756. https://doi.org/10.1016/j.procs.2021.01.227.</ref>. 
#'''Synergies and cost efficiency through focus.''' Entirely and precise planned projects are less likely to trigger cost and time overruns and tend to stay within their boundaries, also they are more efficient due to thoughtful planning. By execution of efficient resource planning, the running costs can be lowered significant compared to a more adaptive approach. All the gatherings and analyzing of information prior the initiation leads to more concrete estimates of costs and time. By approaching individual steps instead of merged connected, but assorted tasks, 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 projects more often within their boundaries of budget, time and schedule compared to agile management<ref name="Thesing"></ref>. 
#'''Simplicity.''' Smaller, individual tasks within similar fields of work are easier to manage compared to large scale parallel practices. Less complexity leads to higher probability 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, the classic, predictive approach is preferred since it is easier to adopt to their structures compared to adaptive approaches. 
#'''High quality results, that meet the project goals.''' Even in sensitive projects with high risks of total loss, risks can be reduced to extensive research and information gathering before head<ref name="PMBOK"></ref>. High amount of decision making and estimation about robustness of the project takes place. This form of model results in detailed documentation about each step and includes robust testing during the verification phase. As each phase gets specific outputs, they are easy to review and assess regarding the success of the overall process. The extensive resources used for each phase lead to a high-quality output, 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<ref name="Thesing"></ref>.

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

#'''Inflexibility.''' The waterfall model generally is inflexible in terms of changes after the initiation and planning phase of the project. However, there are change control process who can be implemented and integrated into the process to have limited abilities in terms of changes. When changes either through adjustments of the original plan or through detection of problems have to be made, it is often hard to implement them during running processes. In terms of changes the different options and outcomes must be assessed carefully to decide about ongoing and trying to correct them later or go back during the process and basically re-start from the beginning under the updated circumstance<ref name="PMBOK"></ref><ref name="Thesing"></ref>. 
#'''Late detection of problems.''' Occurring problems often getting detected relatively late in the project. Due to the lack of testing or validating of solutions and concepts in early stages, problems and failures can be overseen or weaknesses of the concept are not getting properly detected and therefore found relatively late in the 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-time projects there is often a lack of information from the beginning. This risk can be minimized by applying consequent stage-gate checks. Therefore it has to be considered before a project if the waterfall model is the best choice under the given circumstances<ref name="Thesing"></ref>.<br />
#*Both problems, often in combination, the occurrence of a problem at a late stage of the project and the difficulty to make changes or corrections can lead to severe cost and time overruns! <br />
#'''Low stakeholder engagement.''' Beside the initiation and planning stage in the early phases, there is generally low stakeholder engagement during the execution. 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<ref name="Thesing"></ref>.
#'''Unpractical for certain types of projects.''' The waterfall model is generally not suitable for object-oriented projects which consists of high uncertainty, risk or incomplete and unverified information. Nevertheless, it is indeed suitable for complex projects, as long it is feasible to create a detailed project plan in the beginning<ref name="PMBOK"></ref>.

==Connections==
[[File:Leeres Diagramm - Seite 2.png|450px|thumb|'''Figure 4''' Relationship of complexity and approach. Own figure based on <ref name="PMBOK"></ref>]]
Especially in the field of software development, the common practice has been further developed 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 back-steps as in the cascade model evolved. In terms of predictive planning the V-model is widely used today<ref name="SDLC"></ref>. 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<ref name="Boehm"></ref>. Therefore, it is to mention that these methods can be, like the waterfall model itself, applied to various kinds of scenarios and are not limited to a specific use case alone, but depending on the individual assessment of requirements, knowledge and information of a project it is to consider if the higher expenditure is generating additional value or if generally possible to achieve the same outcomes compared to the simpler predictive methodology<ref name="PMBOK"></ref>.

==Annotated Bibliography==
'''Project Management Institute. (2021). The Standard for Project Management and a Guide to the Project Management Body of Knowledge (PMBOK Guide).''' The book provides an overview to all project management related topics. In the context of project planning, it is not only important to understand how to apply a model, like the waterfall model, it is also necessary to understand which actions and tasks must be done in preparation to a project and how to proceed certain steps during a project. The book provides comprehensive knowledge as well as guiding through related topics which not only do influence the outcome of a project itself, but also have an impact on the preparation and execution. This includes the gathering of information, decision making and more influencing factors as well as the managing of projects with a predictive approach in general.

'''Thesing, T., Feldmann, C. & Burchardt, M. (2021). Agile versus Waterfall Project Management: Decision Model for Selecting the Appropriate Approach to a Project.''' The paper published by T. Thesing et al. does not only provide a comparison between advantages and disadvantages between the predictive waterfall method and the adaptive agile method. They also present insight and feedback gained through an empirical survey among decision makers and project managers from the industry. Furthermore, they provide a hands-on and usable decision model for the selection of an appropriate approach for a project.  

'''Kneuper, R. (2017). Sixty Years of Software Development Life Cycle Models.''' The paper gives a comprehensive summary about the evolution of different approaches over the last 60 years. While the paper itself focusing on software development and related methods, most of these models are transferrable for interdisciplinary application. Furthermore, different models getting and their evolution, with most of them having roots to the original waterfall model, getting presented.

==References==
<references/>