Don’t Go Chasing Waterfalls: 2 Reasons to Avoid Waterfall, and 3 Better Approaches
There are many reasons why the waterfall approach does not work for most technology projects. Though many companies still use some version of the waterfall methodology to manage all projects, the fact is that the approach is arcane, outdated and essentially useless for software implementations.
Have you ever tried to walk or climb up a waterfall? I tried walking against a waterfall in Jamaica once, and it’s a pain to do. The waterfall methodology for projects is aptly named, because it is equally painful to try to go back to prior phases of a project once the effort has advanced to the next phase. This article will outline two reasons to avoid waterfall, and three ways to approach software projects that are more useful.
Reason 1: Construction projects are different from software projects.
“The cost of a thing is the amount of… life exchanged for it.” – Henry David Thoreau
The waterfall project methodology was created for construction projects, where the cost of rework is extremely high and the controls over phases need to be extreme. Consider if your company had just completed a building, and you discover that the foundation is not level, and is not made of durable material. The cost to rebuild the foundation (by, most likely, destroying the building,) is unbearably high. Therefore, the levels of design and inspection rigor need
Please log in or sign up below to read the rest of the article.
|
"I may not agree with what you say, but I will defend to the death your right to say it." - Voltaire |




