Waterfall vs. RAD:

Comments 0

Facebook 2

Linkedin

Twitter

More

The waterfall and rapid application development (RAD) processes are not the only two methodologies available, but they generally predominate among methods used to deliver projects. Each has its individual merits, but sometimes one method is more appropriate for a particular project than the other. In this column, I will look at when to select each of these approaches.

As I mentioned in prior columns, I believe most, if not all projects, can be delivered with the waterfall methodology: plan, analyze, design, construct, and implement. In contrast, not all projects are candidates for RAD. Perhaps the best starting point is to take a look at some project characteristics that govern which method is best.

Details on waterfall and RAD methodologies To find out more about the methodologies, read these articles: •"Examining the life cycle of a RAD project"
•"How does the waterfall development methodology play in the enterprise?"

How big is the project?
One of the basic tenets of RAD is focusing on smaller projects that can be launched quickly and concluded with tangible deliveries. However, not all projects can be broken down into smaller pieces because they are too complex and interrelated to be split up effectively. There is no rule of thumb to determine how small a project needs to be before it is a candidate for RAD, but the larger you get, the harder it is to use the RAD model.

On the other extreme, if you have a small project to begin with, you might as well go quickly through the traditional waterfall process. If the requirements are not overly complex, document them all at once and be done with it, rather than go through a series of prototype steps to discover them all.

Do you need a prototype?
The beauty of the prototype is that it provides an early look at the solution and it allows the customer to develop a better set of requirements through an iterative process. However, a prototype is not applicable with many projects.

For instance, if your project involves implementing batch processes, there may not be much value to a prototype. Stick with the waterfall process on these projects. On the other hand, Web projects, because of their visual nature and the ability to reuse many components, lend themselves well to the RAD approach.

Are you using a packaged solution?
The RAD methodology and the use of the prototype imply that you are building something. If you are implementing a packaged solution, a RAD approach probably will not work as well. It's also hard to break a package implementation into smaller pieces. In general, if you are working with a packaged solution, the waterfall approach is better. The exception is that the more customization that is done to a package, the more opportunity there is to use the package in a prototype mode and utilize RAD in general.

How flexible is your team?
The waterfall method is best when you want everything documented and you want to force all proposed changes through scope-change management. By its nature, RAD requires a high degree of flexibility and the ability to manage through change. For instance, your initial prototype may generate the type of discussion that will require the next version to be created completely from scratch. Organizations or teams that cannot adapt well to change should not use RAD.

How much will your customer participate in the process?
The waterfall process requires heavy user involvement during planning, analysis, and testing. The RAD process requires the heavy involvement of customers in the phases of planning, analysis, and testing, and then over and over in the prototyping process. If you find it hard to engage the customers on an ongoing basis, then RAD and prototyping will not work for you.

Is your project manager experienced?
Although the project management processes may not be as rigorous, the cyclical nature of a RAD project requires a great deal of discipline and organization on the part of the project manager. If your project manager is inexperienced or does not possess strong organization skills, you probably do not want to undertake a RAD project. Stick to more traditional waterfall projects instead.

Selecting the best method
Most projects can be executed using the traditional waterfall process, and I think it is typically the safest approach. In fact, if it is appropriate, there are several techniques that can be used to accelerate project delivery with a waterfall approach. For instance, a large project can be split into smaller, more manageable pieces, with the subprojects utilizing waterfall methodology as well.

However, as described above, many projects are candidates for RAD development. When you need a good visual prototype, and if you can keep the users engaged to define requirements quickly, it is possible to deliver a series of RAD projects sooner than one larger waterfall project. The customer also gets the added benefit of being able to use partial functionality very quickly as the earlier projects are delivered. During your planning process, examine the characteristics of each project to see if one development process will be more applicable than the other and then utilize the one best suited for your project.