Following on from the post, Choosing between Waterfall and Agile project management. This post will go in to more detail of the Waterfall Project Management methodology.
What is the Waterfall method?
The Waterfall method is considered to be the traditional method of project management. It follows sequential steps in a linear fashion, with each step being completed before moving onto the next. A return to previous steps is not permitted with this method, so any steps that need to be re-done means a return to the start.
It is rooted within the manufacturing industry, hence it’s rigid process. If you think of a product on a production line, it goes through and completes a series of steps before the end product is produced. Take a can of food for example, you can’t seal the can before the contents have been poured in. Similarly, the contents can’t be unpoured if there has been an error, it has to continue through the process.
The rigidity of this method means that you must get it right first time, highlighting the need to have all of the required information at the beginning of the project. The information should be documented methodically, before being distributed to all team members. This ensures that all members fully understand their role and what is expected of them. The information can also be referred back to at any point in the process.
Phases of the Waterfall method
The phases involved may differ slightly according to industry, however the basic steps remain the same.
The Waterfall method is commonly used in software development; however, we’ll stick to the traditional manufacturing roots to describe the phases of product development.
Firstly, the requirements of the project are gathered and documented in detail. If you are developing a product then you will need to identify things such as features, specifications and costings. The requirements can be gathered from consumers through surveys or focus groups.
The focus at this phase is to understand how the product will be made, which is determined by the requirements. Mock-up products may be constructed, and materials discussed. If the product is being made externally, then collaborations with suppliers and manufacturers will take place here.
Here is where the project physically begins. Although the manufacture may be in other hands, it is still the Project Managers role to make sure that the process is on schedule to produce the number of products required.
You have your physical products, so now you need to test them. The most appropriate way to do this is to take a sample of products, across different batches and test them against the requirements. Any issues should be recorded, and a further investigation conducted to identify the scale of the issue.
The final phase involves fixing any issues that the customer identifies, and handling returns and replacements. Again, issues should be recorded and further investigated so that they can be fed back into the requirements phase for future products.
The reason this method has been a mainstay for so long is because of its simplicity. Members with little experience of project management can get started straight away without formal training, and new members can join at any stage. This is because the strict documentation requirement means that a read through can get everyone quickly up to speed.
The end goal is clear to all members at the beginning of the project, and comprehensive documentation at each stage allows progressed to be monitored easily. This ensures that the project stays on track and the Project Manager can identify when the project will be completed without the need for guesswork.
Its simplicity means that the Project Manager doesn’t need to manage every member of the team at the same time, they can just focus on the team members involved in a particular step within the process.
Whilst proving an effective methodology, the Waterfall method can be viewed as outdated.
One of the main criticisms of this method is that testing is saved almost until the end, by which point significant time, energy and money have been put into the project. An undetected error in one step of the project could be carried into the next step, putting the whole project in jeopardy. Errors and changes could result in a return to the start and significant delays in completion.
If changes do need to be made, either because of errors or changes in requirements, the rigidity required in following the steps sequentially leaves no scope for this.
Having a clear set of requirements before starting the project ensures that it runs efficiently from an internal perspective, however the Waterfall method excluders the end user from the process. Comprehensive information gathering at the start can also result in a delay to the start of the project.
From the Project Managers point of view, this method requires strict and regular monitoring to ensure that the project is on track.
It also requires a robust change control process to ensure changes are only introduced when the full impact is known and all stakeholders agree. More details of change control processes can be found in Overview project change control process.
Should you use the Waterfall method for your project?
The Waterfall method should be used when you have a clear set of requirements and all of the information up front. If the project is unpredictable and you anticipate any changes, then you should consider a different model.