Project management veteran Tom Mochal periodically responds to questions and discusses issues that Developer Republic members have raised. This is a great way to learn about the problems and concerns that others have and to get valuable advice on the issues developers face every day.

When comparing the waterfall methodology with an iterative methodology, such as Rapid Application Development (RAD), I don’t think the waterfall approach is as good as RAD in a couple of areas:

  • Feedback from the customer is delayed in the waterfall life cycle.
  • Flexibility for change in business requirements is not accounted for in the waterfall approach.

Waterfall seems better suited for a structured language like COBOL and just doesn’t work well with OO languages. How do you think the two methodologies stack up in these areas?


You have made good observations about the differences between waterfall and RAD methodologies. Let’s take a closer look.

Is feedback from the customer delayed in the waterfall method?
In general, I think feedback is delayed with the waterfall approach. You may have active customer involvement during the waterfall analysis phase, but then you go through a design and construction phase before you start to show the customers any aspects of the application. With RAD, you take a subset of the application, do a quick analysis, design and construct, and bring it back to the customer for feedback. You then modify the application based on that feedback. In a traditional waterfall process, the customer sees most, if not all, of the application at once. In a RAD process, you show them pieces of the application much earlier.

How about changes to business requirements?
While it is true that changes to requirements are an expected part of the RAD process, I don’t think the waterfall method is inflexible in this regard. With RAD, you start off with a partial list of requirements, build a solution, and show the customer. They then give you more feedback on requirements and you incorporate those into the solution. This repeats until the application is complete.

However, in a waterfall approach, you can handle change through scope-change management. Once the initial business requirements are completed, you begin work on design and construction. If new requirements are added at any time during the remainder of the project, you submit a change request. The team then determines the impact to the project of making the change. In many cases, there is no measurable impact to the project. In other cases, major changes can force a project to take more time and cost more. This is especially true if major changes are seen toward the end of the development life cycle—say, during system or user acceptance testing. But the same thing can occur using RAD methods. You could be completing your third iteration when a requirement change comes in that will necessitate a major rework.

Is it best to use waterfall for structured languages, such as COBOL?
I don’t think there is necessarily a relationship between the methodology you use and the language you develop in. But it’s true that some technologies lend themselves better to one approach or another. For instance, Web development is heavily oriented toward the user experience, making it a good candidate for the RAD process. COBOL is typically used for high-transaction online and batch systems, which may not be as good a candidate for RAD because there is nothing to show the user when a lot of the transaction processing takes place in the background. So there may be a link between the development methodology and the language, but it’s an indirect link based on the nature of the application.

Different tools for different situations
Both waterfall development and RAD are viable models for developing applications today. In many cases, the choice of what process to use is based on the type of application being developed. The more user interaction there is, the more that you can show the customer to get further input for additional requirements. Applications that have a heavy component of behind the scenes processing may not be as good a candidate for RAD since there’s less to show the user.

You should also consider whether you have the customer engaged enough to make RAD development work. In RAD development, you need ongoing customer involvement. If you don’t have it, RAD will not work well, even if it would be a good approach based on the application characteristics.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.