People have been using the Waterfall method for years without realizing its name, as buildings, public infrastructure, and all industries have been applying this model to plan their workflows. Of course, the world has changed, and the demands have followed suit, but some things remain the same.
In this article, we will see what the Waterfall model is, how it works, the benefits of applying it and when it falls short against Agile workflow methodology, for example.
1. What is a Waterfall model?
The waterfall method is a stage-by-stage, step-by-step project management approach where a project is split into clear stages that move forward after the completion of each. This happens in a linear sequential pattern. Each next stage is dependent on the previous one and based on a firm upfront plan of action. It is perhaps the most traditional way of project management, which works on building on successive stages to the previously developed one.
Waterfall is a logical form of management that has been commonly used in manufacturing and construction. The clearest example is the building of a house, where you should complete each stage before moving on to the next one.
Within the field of software development, Waterfall was the first strategy used, but the most basic model was often criticized for its lack of flexibility and adaptability, as well as the risk of failure through lack of testing and, therefore, the need for a complete redesign. This led in part to the take up of Agile strategies, such as Scrum and Kanban. However, Waterfall has proved adaptable, too, and it is having a new resurgence (with some significant tweaks) and earning back its reputation.
2. Model
Whilst Waterfall as a system has been around for centuries, it was so intuitive to the old ways of project management that nobody has formally classified or indeed named it. In 1976, Winston Royce formalized this classification and breakdown into set phrases, setting the scene for Waterfall in software development.
Royce’s formal original waterfall model, which constitutes the set phases followed in order:
- System Requirements – documented
- Software Requirements – documented.
- Analysis – models and rules to follow.
- Design – a draft for a software construction plan
- Coding – the development of the actual software
- Testing – the QA, debugging, and fault finding
- Operation – the installation, support, and maintenance
This is a model that needed improving, as the obvious defect was the lack of testing and feedback during the design
3. Royce’s Improved model
This includes the acknowledgment that testing code and then redesigning the software if necessary is vital. This could affect the specifications, removing possible conflict and maybe adding other additions. There is also a note regarding greater client involvement
4. In Practice
Royce’s Waterfall is a base, but different versions have emerged from it. Often what can be loosely termed the planning stages (Royces 1,2 &3) are grouped together. This leads us to a 5 point action plan.
5. What Are The Waterfall Stages?
The stages of waterfall lead directly from one on to the next. At the conclusion of each phase, we reach a “milestone.” This is the result of that part of the process. The next part begins only when we have completed the previous one.
We refer to these stages as:
Analysis
Each Waterfall project starts at the analysis stage. This is the stage that decides whether or not the project is feasible and practical. Firstly it needs to be decided whether it can be done and whether it is worth doing. Then, there is an analysis of the costs against the value of the product. This must include a general plan, requirements, and estimated costs and time. This is what is placed before the client and constitutes the estimate in the offer.
Once the project gets the go-ahead, then we can move into a more detailed analysis. What are the essential requirements we need to deliver? What are the clear definitions of functions and properties that the project should include? Clear goals for the final project and the testing of its successful completion. This is a more detailed build on the previous general analysis.
The next part of the analysis stage adds even more detail to the plan. The requirements are looked at in detail, the project can be broken down into sections, and there is a decision about how these tasks can be completed.
Design
The design phase takes this skeleton plan and adds the flesh to the bones. Here the requirements and different tasks are worked on in detail in order to produce a highly detailed plan of action and construction. A priority list, an order of construction, and an architectural plan. At the end of this stage, there needs to be a detailed draft document of the plan, including the assessments of success or failure.
Implementation
The implementation is the part where we put the full-scale plan into action. The programming, constructing, testing, the problem-solving with each task are executed into the whole on completion to form the final product. The final product is then tested under internal working conditions (alpha testing).
Testing
In this stage, the testing is moved out to the target market environment (beta testing), often to a select group before general release. Other bugs and problems that become apparent are solved, and the feedback is worked on. The product then can be released.
Maintenance
Waterfall includes a final stage, which is the delivery but also ongoing maintenance, and leaves options for further improvements.
As a breakdown of the operative stages, Waterfall tends to spend a lot of time on the planning and design stages. This is essential, as Waterfall’s step-by-step approach and sequential progress mean that without a strong plan, the whole project can be significantly delayed. A problem early on will mean a delay to everything as the next step cannot begin until the other is fully completed.
6. The Value of Waterfall
The value of a Waterfall method is that it has clear organization and structure from the very beginning to the very end. It is a logical, easily followed pattern of progress, fully documented at each stage.
It can be argued that it is too structured and therefore inflexible and therefore only works with projects that are clearly defined and have little chance of changing. In theory, this is indeed the case, but in practice, Waterfall can be adapted, especially if a project is seriously long-lasting.
7. Pros of Waterfall Method
7.1. For the Team
Organized
Waterfall spends a lot of time in the early planning and design stages. This structure and organization mean that there is a clearly defined, detailed, and cohesive plan to follow. Everybody knows what they are doing and the order that they are doing it. Every phase is easily understandable, and every stage show progress and a milestone reached. There is stability that leads to security. It is also clear for outsiders, such as clients, who are non-specialists. They can clearly grasp what is happening, when and why.
Documented
The Waterfall model works with documents from start to finish. The advantage of this is that if new team members come on board, or even if you require a completely new team, they have all the information right there. They know what has been done and how. This includes the design, the requirements, and even the sort code of a software project.
Reduced Costs
Extensive detailed planning should reduce costs in the long run. Potential problems can be ironed out before they’ve even been discovered, and there should be no chance of scope creep.
Employee Planning
We could argue that Waterfall helps the business plan the time of their employees better. If an employee is required at a certain time for a certain stage and not for another, then they can be assigned to another project in the meantime. They know in advance when they will be needed on any project, and this means they can be assigned efficiently and more appropriately depending on their skills and abilities.
Measurable Progress
At each stage completion, Waterfall is one step nearer to the end. What could be an easier way of measuring progress?
7.2. For The Client
Expectations
Detailed planning means that the client knows what to expect from the product. Importantly the estimates for times, delivery dates, and costs should be relatively accurate.
Minimal input
Once the project is up and running, the client can leave the project to the professionals.
8. Cons of Waterfall Method
Client Problems
It is not unusual for a client to not be able to tell you or even not know exactly what they require or want initially. Since the planning phase is so important to the overall success of the project, you need to know the expectations and requirements ahead of the actual implementation. Clients, especially in areas such as software and web design, are often liable to change their minds or want additions. This may require Waterfall to go back to the drawing board.
Potentially Higher Costs
If you have to go back to the drawing board because of the requested changes, this will increase the cost substantially. We aren’t talking about a little tweak. We are talking about a redesign. Although some Waterfall methods do now try to incorporate structures to account for changes.
Inflexibility
With large-scale, long-term projects, especially in fast-moving fields and areas of business Waterfall’s inflexible nature can lead to problems. You may plan brilliantly for the situation at the time, but if the market moves, fashions change, or new technology develops, then your original strategy may be useless. Waterfall model isn’t easy to adapt to these sorts of changes as you go along.
Pressure on Forward-Planning
Much of Waterfall method success is derived from the planning stage. The pressure to get this right is enormous. Failure here will most likely lead to a project failure.
Deadlines Missed
As the Waterfall method is sequential, it only takes one small part of the sequence to fall behind schedule, and the whole project can be delayed. With more problems come more delays which can add up to serious problems meeting the set deadlines.
QA and Testing
There is an argument that Waterfall leaves its testing too late. Doing the testing towards the end of the project means that if problems and bugs are found early on, it is a hell of a job to go back and put them right. Additionally, because it’s near the end, the testing might be rushed to meet the deadlines that are forced because of delays. Even doing the user assessment at the end is risky.
Unpredictable events
Things happen in projects, things that are almost impossible to foresee, things that you can’t possibly plan. The structured approach of Waterfall is so strong, that it can make these issues really difficult to get around.
9. Alternative Waterfall Strategies
Waterfall, in its purest forms, might have some problems. That doesn’t mean it’s all bad, and we shouldn’t throw the baby out with the bathwater. Several different variations and adaptations of the Waterfall method have emerged to deal practically with these potential failings.
Sashimi
An adaptation of Waterfall method that overlaps the stages. For example, the requirements phase needs some architectural input, the architecture needs some element of design, etc. This calls for more communication between the phases and has more flexibility.
Prototyping
Here the first work is to produce a basic working and functioning prototype. We use this Prototype to work through problems, issues, and requirements and to garner client feedback before the actual project begins. Then the Waterfall system is put into action but benefits from the client’s expectations and feedback as well as learning the lessons from the previous model regarding potential issues.
Other models that have some elements of Waterfall include models such as Spiral, Rational Unified Process, and Incremental. The idea is to take the logic and sequenced structure of Waterfall but also mitigate risk.
10. What Kind Of Projects are Best Suited to Waterfall?
It seems clear, given the advantages of Waterfall in some areas, yet the concerns about it in others, that Waterfall is not perfect for every type of project. The more detail, the better, so that the essential planning phase can set into action the whole plan and be confident of success. Waterfall works well under the following conditions:
- Fixed Scope – if the ideas are clear from the start and will undergo no change in time.
- Fixed Budget – since you plan in advance, Waterfall will suit fixed-price projects perfectly.
- Low-Risk – if the project isn’t complex and doesn’t require much work, the Waterfall model is suitable.
- Fixed deadline – in general, the Waterfall method performs well with deadlines because of the detailed planning.
- Short, simple projects – projects can be completed before the market conditions change
- When user feedback is expected to be straightforward
These factors are perfect for one-off projects or projects that are based on something that already works.
11. When Not to Use Waterfall
It is perhaps not a good idea to use waterfall for certain types of projects. Be wary of using Waterfall if:
- Clients aren’t clear on the details
- The requirements aren’t set out immediately
- The project is part of a dynamic industry
- You expect to add additional features at a later date
- User feedback is the basis of the product.
The waterfall isn’t a good idea for experimental, development projects, or complex projects that can potentially take a lot of time to complete.
In Summary
Waterfall’s big advantage and the reason it has been around for so long and will continue to be so is its intuitive logic and sequenced structure. It works and has worked. It is straightforward and obvious, and doing it correctly means it is understandable and relatively risk-free. And despite its shortcomings for very dynamic projects, or when clients don’t know what they want, the Waterfall method is still a preferred option for many non-complex software development projects, as well as a must-have ingredient in many industries where planning is key.