Small project teams tend to use flexible and clear methodologies with short iteration cycles. However, each team may have its own preferences. In some cases certain mechanics are already in place, while in others the project or development object itself requires the use of a specific management system.
Usually, the choice is between Scrum (based on the «race for new features» model), Kanban (with the transfer of task cards by column states) or Waterfall (also known as the cascade model).
In the following, we will focus on the practice of project management using the Waterfall methodology.
Basic principles of waterfall projects (how this model works)
As you can see from the name, the main order of action is downwards — from top to bottom, as the importance and urgency of tasks, i.e. cascading (as in a waterfall).
Project development within a waterfall is strictly sequential. You cannot start a new phase until you have completed the previous one. Also, you cannot go back to phases and tasks that have already been completed.
The principles of the waterfall approach and the name of the methodology are often attributed to W.W. Royce and his 1970 research paper. In fact, the name Waterfall was first used in the work of Bell and Thayer in 1976. And Royce only mentioned 5 steps in his article that were designed to reduce the risks of sequential project development. For example, the fact that testing is only done in the last stages was identified as a problem. This can have serious consequences and even lead to the complete failure of the project.
So what does waterfall involve?
- The requirements for the system to be developed and for the software should be outlined in a Product Requirements Document (PRD).
- Analysis phase (the output should be models, diagrams and specific business rules).
- Design/interface development (the output should be a clear architecture of the software product).
- Code Writing (development, performance testing, integration if necessary).
- Testing (the stage of comparing the planned functionality with the actual one, debugging errors).
- Further operations — installation, migration (if there is old software), maintenance and support of the product.
In a more modern interpretation, the last stage is divided into two independent stages: the installation and commissioning stage, and the maintenance and support stage.
This is a very clear and quite functional scheme. It is still used when working on various types of projects, including large ones (especially in the public sector, where contract software delivery schemes are often used).
What are the benefits of the waterfall model?
The most complex and responsible stage is the planning stage (requirements generation). It may require special software solutions, such as a convenient task planner (preferably in online format). All the other stages take place within the framework of the compiled task list.
The waterfall model is therefore as simple and straightforward as possible. Everything is logical and follows familiar phases.
The second major advantage is the clear structure. The backbone of the project is rigid and does not imply deviations when working on tasks. There are no surprises, no switching to more important features, no reworking on the fly, no paradigm shifts, etc.
With a clear network schedule, you can plan people’s workloads in detail and track the progress of tasks. Transparent control is always the key to success.
Like any rigorous methodology, the cascade model implies the development of detailed documentation. And good documentation, in turn, ensures a lower entry threshold for new team members and their interchangeability. At any stage, it will be easy to replace a developer who has left or who suddenly falls ill.
With a cascading model, it is difficult to run out of time. Therefore, the project is very likely to be delivered on time, with no burning deadlines (especially if cost time has been built into the plan).
Like any other rigid methodology, the cascade model implies the development of detailed documentation. And good documentation, in turn, ensures a lower entry threshold for new team members and their interchangeability. At any stage, it will be easy to replace a developer who has left or who suddenly falls ill.
With a cascading model, it is difficult to run out of time. Therefore, the project is more likely to be delivered on time, with no burning deadlines (especially if time for delays has been built into the plan).
Disadvantages of Waterfall
The rigidity of the approach is also a disadvantage. Even in business development, not everything goes as smoothly as we would like. Customers often change their tasks and requirements, new options and features can emerge in the development phase that require separate approval and redesign, and so on.
With the waterfall model, you can’t go back and redesign. You can only go forward until the end. Redesign and rework are only possible in the next iteration — with its own stages of requirements gathering, analysis and design, implementation and so on.
With waterfall, the risks are as high as possible. If something hasn’t been considered at the design stage, you can’t go back and change it. You have to stop the whole development process and start all over again. And that is a loss of time, resources and money.
Planning complexity. A lot depends on the experience and skills of the developers. Without accumulated knowledge, you will not be able to properly plan a complex or large project. There is a high probability that you will run out of budget or time to develop key functionality or rework.
In which projects should waterfall be used?
Many sources claim that the model is only suitable for small and low-responsibility projects. In reality this is not true.
The only important criterion is to have clear initial requirements for the final product. The clearer the final picture, the easier it is to implement.
You can achieve this result in two ways:
- Your clients or customers understand exactly what they want, how much it will cost and in what timeframe.
- You know how to do the job according to the client’s initial requirements — you have the experience and knowledge.
But the project itself can be any size and any level of responsibility.
However, waterfall is definitely not suitable if neither you nor the client have a clear understanding of the end product, or if there is a high risk that new subtasks or even a complete change of course will occur during the implementation process. For example, if you need to develop a product that you have never seen before, look for alternatives to Waterfall in the list of more flexible methodologies.
How to reduce risks
In reality, you can combine different approaches. Nobody forbids you to use a combination of Waterfall+Kanban+Scrum in a team. The main thing is that it works and delivers the desired result.
To mitigate risks, use dedicated solutions — software for project control, tasking, notifications and discussions, preferably in a cloud format so that it’s easy to connect new members within the team or on the customer side.
The second point is to divide the final product into different modules. Then it will be possible to work with each of them according to the waterfall model. The iteration time from requirements definition to project delivery is significantly reduced, as is the amount of risk.
