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[1]. 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[1].
Contents |
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 [2]. 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[3]. 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[4]. 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[5].
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 [3]. 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 [6]. 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[1]. 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[7].
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[8]. The model primary used in project management contains 5 phases and is based on the four-step life cycle: development, realization, utilization and disposal[9]. For each phase there are defined start and ending conditions as well as 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. Based on this process the following phase can only be started if the previous stage and their defined goals and criteria have been met. The 6 generic phases are:
- 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. - 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. - 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 - 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. - 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. - 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.
These phases are more to understand as guidelines instead of rules. Another common practice is to use the extended cascade model. 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, one step up to the next higher hierarchical phase can be done to correct the problem, whereas a skipping of several phases is not intended.
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 before the start. Changes during the problem are not intended and in change of problems causing high costs or time overruns. Usable: for project with early definition of requirements, performance measure and processes are 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, therefore it should be categorized as project. [insert source p def] The waterfall model is not intended to be used in continuous projects. Example: construction or manufacturing project but also cooking receipts fall into this category.
- Intermediate steps are getting planned with a high level of details. This includes budgeting and step by step planning in a linear manner.
- Project planned with the waterfall model usually include a high level of governance by the centralized management team and non or less unpredictable changes are expected
Variants
A common practice in more complex projects is the to extend the waterfall model by cascades. 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. It is not intended to go back more than one step; therefore, the original linear structure should be kept. 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 of the use of cascades must be evaluated individual before a project. For example, a use during a construction project does not make sense, whereas a use in manufacturing to update changed information often make sense. Another approach is the V-model, especially in software development.
Application in Project Management
Examples
Advantages
Limitations
Connections
Annotated Bibliography
Project Management Institute. (2021). The Standard for Project Management and a Guide to the Project Management Body of Knowledge (PMBOK Guide).
References
- ↑ 1.0 1.1 1.2 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.
- ↑ 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.
- ↑ 3.0 3.1 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).
- ↑ 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).
- ↑ 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.
- ↑ Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5), 61–72. https://doi.org/10.1109/2.59.
- ↑ International Organization for Standardization. (2020). Project, program and portfolio management - Guidance on project management. (ISO 21502:2020).
- ↑ International Organization for Standardization. (2020). Project, program and portfolio management - Guidance on project management. (ISO 21502:2020).
- ↑ Züst, R. & Troxler, P. (2006). No More Muddling Through. Springer Publishing.
