Waterfall Project Management (Waterfall PM) is one of the styles of project management that I discussed in an earlier article. It is like any of the other models of project management — you need to study the process represented by the particular style to understand if it will work for you and your situation. I have used it in some projects where the needs of the client and the particular project require careful monitoring of the quality of the outputs of the project and when going back to fix a component of the intended outcome would be cost prohibitive.
Waterfall PM is named such because when you use it, you have to think of your project as a waterfall, cascading from one step in the process to the next. The process that guides you through your project flows through the eight steps of the process: 1. Project Conception, 2. Initiation, 3. Analysis, 4. Design, 5. Buildout, 6. Product Testing, 7. Production/Implementation, and 8. Maintenance. After first glance, it is obvious that this model can be used widely in a project that is linear and where any mistake early in the project would cost you a significant amount of time and resources to fix later down the line. Measure twice and cut once right? Programming, product development, and construction are three industries that can benefit from the application of this strategy. In later articles I will examine in detail Agile Project Management and the differences between it and Waterfall PM.
I think Waterfall PM used in the software or tech industry can be super effective where thousands and thousands of lines of coding can be thwarted by simple mistakes or where cross-platform requirements can throw a wrench into your efforts. If you are able to prevent most mistakes that are going to happen during the buildout stage from moving on past the product testing phase, you can save a ton of money, time, and resources later in your project. The truth is, using this strategy may be the difference between hitting and missing your deadline and delivering a product that actually works.
Personally I think the strength of this model is in the first step — project conception. As a project manager in any industry you will be working on a project for either internal or external clients. Specifying the traits of any product that will be designed as a result of your project is imperative to any type of project. The requirements of any output of the project should be detailed, agreed on, and set in stone before your project begins. Using Critical Path (CPPM) strategies, this is called the project scope. Using the waterfall style it is typically called a design document — it details the required functions of the output of the project. There is little flexibility in the features of the output once you have started in the design process.
I for one like to practice what I call “flexible waterfall project management“. Practitioners of a pure strain of Waterfall PM will undoubtedly believe this is impossible. But, you need some flexibility in the process. It is unlikely that as you work you way through the first four steps of the process that you will know exactly what you need. You may also come up with better solutions through the process. It is silly to continue through a process with your original idea if you have come up with a better solutions during the process or if your needs have changes. Your output will be obsolete once you reach the production/initiation phase.
So I go back to the importance of the design document. If your changes/improvements fall within the parameters of the design document, then you should proposed making viable improvements with your stakeholders. They should make a decision based on criteria that you established during the initiation process. If the changes and improvements would render your project obsolete, then perhaps it is best to close the current project and start over. As painful as that is — nobody likes to lose — it can save your company money, time, and resources in the long run. Backtracking is hard, but ultimately can be the best decision if you are going the wrong way.