From the course: Blending Project Management Methods

Weaknesses of defined processes

From the course: Blending Project Management Methods

Start my 1-month free trial

Weaknesses of defined processes

- Waterfall project management started in manufacturing and construction. It's linear nature makes complete sense. Each phase had to be fully completed before the next phase could begin. For example, you can't put up drywall before you lay your foundation, you can't paint the car door if the car door isn't made yet. In this type of environment, waterfall methods have a very high success rate. However, when waterfall and its defined process control was moved into the realm of software development, its success rates have dropped. In the software realm, the failure rate of waterfall projects is 29%. Failure is defined as projects that are either canceled or completed but the product isn't used. At the same time, the failure rate of agile projects came in at 9% for the same time frame and with the same definition. So why does waterfall frequently fail in software development? Well, first of all, software is not the same as construction or manufacturing. No two applications are the same. Two cars can come off the assembly line exactly the same, but no two applications are ever the same. You can follow the same steps in a software development project and yield completely different results, because software is different and each application is so unique. Another challenge with the waterfall process is its inflexibility. Each phase has to be fully completed before the next phase can begin. So if you learn something in the third phase or the fourth phase, you can't go back and change it. As you're developing software, you're learning things as you're going through, but it's difficult and expensive to go back and make changes, because you're affecting your time and you're affecting your cost. Next, the separation of the phases restricts teams from being able to adapt. Again, you can't discover something in execution and back up to planning, make some changes, go forward, learn something, and back up again. The impact of this defined process segmentation is that teams will build what is designed even if it's not the best thing to build, because it's expensive to stop and change. In the end, you end up with an unusable product. Another challenge is that since each step is segmented, each activity is separated, and it has an impact on how you pull things together. For example, you always test after development is complete. By the time you get to the testing phase of a waterfall project, most of your software developers, who were only temporarily assigned to your team, have moved on to other projects. When bugs are then found, you may not have any developers left on your project to pull back and fix those bugs. The result is that you end up with a lot of bugs released into production. Remember, waterfall methods can be successful in certain contexts. It's important to understand the weaknesses of the defined process. With this information, you can start your waterfall process with full awareness.

Contents