What’s the Waterfall approach?
The Waterfall approach is a traditional project management methodology. Before Agile it’d been the most common According to it, the process is broken down into phases, every one of which has a goal to achieve. When you finish one phase, you go on to another. It’s called “Waterfall” since the results of one phase “flows” into the next one. The problem is you can’t kick off another phase until you’re finished with the current one, so there’s no overlapping over there. Therefore, it resembles a relay race. We plan everything upfront and if something doesn’t go according to plan, we’re in deep water, as this makes the process come to a halt.
5 phases from start to finish
At this stage we define and gather requirements from the client, analyze them and provide an extremely detailed plan how to deliver them. A lot of documents are created there. We need to ensure they’re feasible to implement. We take into consideration the scope, the budget and the timing of the project that are fixed.
At the stage the system/product design is created in accordance with the requirements governed by the project manager. Design specifications are created, analyzed and evaluated to understand what a real product is going to be like.
We get down to work. In software development industry we code, while in marketing we boost sales. The project manager assigns the tasks for team members and monitors their progress. He also makes sure if the work is done they way it was agreed. Any deviation from the original plan might endanger the budget and timing.
After we’re finished with our work, we test the product to detect any potential errors, and make necessary improvements. We need to draw attention to the fact that verification takes place at the end of the process and not on the way.
This stage concerns deployment of the product and its maintenance, which again requires testing. You update the product with new functionalities or modify the ones you’ve already provided. This is to make sure everything works the way it should. The requirements are our success benchmark.
The waterfall approach – features
When to use it?
This methodology was primarily intended for software development. Although it’s not an innovative methodology, it’s still successfully being used in a lot of sectors. Because of unchanging, strictly fixed, detailed requirements, it’s rather recommended for smaller projects of low uncertainty. In other words, in simple environments where we’re able to predict potential problems and come up with effective solutions to them. A simple environment means we’re able to list all the functionalities of the product before the project actually starts. The known-unknown world.
Possible problems of the waterfall approach
1# Changes are unwelcome
There is almost no room for a change here, as the scope, budget and requirements are all fixed. That can cause problems if there are some obstacles in the process. The project manager needs to control change so that the project management triangle don’t cross the line. That makes this method effective for projects with clear, unchanging goals from start to end.
2# Late testing
Suppose during testing it turns out the product isn’t something the client really wishes for. Since we test so late we might be showered with lots of issues that we could detect much earlier. That may lead to getting the product that doesn’t work. In this case, we’d have to review earlier stages which might cost us a great deal of time, energy and cash.
3# Focus on internal process and not a user
The main focus is placed on the internal process and not the person who is actually to use the product. Any idea is planned upfront, so there is very little room for the client to share their own ideas. The client provides the requirements in the very beginning and waits for the outcome. What if they change their mind on the product vision? In this case, the project might prolong which can cause the cost to increase and delay its delivery.
Conclusion
The cascade methodology is good for small, obvious projects with clear and fixed requirements. It’s therefore not as effective as Agile methodologies as far as software development is concerned. However, it’s effective in the environment in which testing along the way is not possible, as there is no prototype yet. if you build a house, you can’t test two walls you’ve just erected, can you? Would you test the walls? There are indeed some projects that this methodology is great for. That’s not software development, however. I’II explain why in the next blog post.
