Share This Post

When you hear the terms “risky” and “invites failure,” do you imagine a successful project methodology?

The debate between waterfall and agile methodologies can be found in any analysts’ meeting of the minds. The linear approach of waterfall methodology runs the project in one large cycle. Agile methodology takes the project in cycles, taking time at the end of each cycle to re-evaluate priorities and keep risk low.  Dr. Winston W. Royce coined the methodology term “waterfall,” however it may have just been by accident. In the 1970 paper Managing the Development of Large Software Systems, a graphical depiction of the software lifecycle is presented. We see the flow of requirements from a top-down structure, all pooling into the testing phase.

When the testing phase of a project following the waterfall methodology is in place, it is essentially the end-all of the project cycle. If a change is necessary, the team doubles back to the requirements phase. “Either the requirements must be modified, or a substantial change in the design is required.” (Royce 2)  Relating the aforementioned term “risky” to a project in this way, a team or business might think twice about adopting this methodology.

In the field of economics and investing, risk is often mitigated by diversification. You never want to pool all of your resources into one industry, country or mutual fund. Let’s suppose you place your entire investment into the Brazilian copper industry. What happens when a small disruption occurs to your single portfolio? Risk can be a multiplier of loss- thus, any disruption (hyperinflation in Brazil or a natural disaster) will become exponentially more disastrous to your wealth. It seems obvious here that you would not want to risk all of your investment in this way. Software development methodologies are similarly applicable to the risk factor. Taking the waterfall approach is like placing all of your funds into one risky investment. A disruption, mistake or incorrect analysis may not be discovered until testing. At this point, it is too late to pull out your investment. Your schedule and/or costs will take a hit.

Dr. Royce makes this point throughout his paper. The “origin” of the waterfall method begins by illustrating the flaws within it. The latter pages of the paper outline ways to mitigate the risk of the waterfall method. Diversify your project by allowing a bilateral flow between stages. Be careful not to place all of your investment into one portfolio. Your team may be able to avoid any mistakes or changes, but why take the risk?

More To Explore

Email in toolbar

Getting More out of Transactional Emails

Are you taking advantage of all of the opportunities to promote your brand? Emails are great way to interact with your customers, and both marketing and transactional emails can be

Visuals in Requirements Mapping

In Praise of Requirements Mapping

Learn how to tie software requirements together with visual models and other artifacts created during the analysis process.