Product development methodology can be broadly classified into spiral development and waterfall development. Each method has advantages over the other for some types of developments.

Spiral development (sometimes called iterative development or incremental development) relies heavily on synthesis before analysis, while the waterfall method relies heavily on analysis before synthesis.

In spiral methodology, a minimum amount of analysis is done, then immediately a candidate design (prototype) is built. Often the design specification (if it exists at all) is short on details or contains a lot of "TBD"s that are intended to be defined during prototype testing. The prototype undergoes rigorous testing and a new prototype is built based on the testing. This process iterates until the design is judged "good enough". The challenge in the spiral methodology is knowing what is "good enough" and how many iterations it will take to get there. The spiral methodology is the harder choice to plan and budget because of the uncertain nature of how many iterations it will take.

In the waterfall method, a very compete specification is generated first, then a prototype built. The planned testing of the prototype is usually limited to verification of the design against the already written specification. While an iteration of the design is always possible (and allowed for in most companies' formal design practices), the waterfall plan usually does not contain schedule or budget for an iteration. This methodology is the easier choice to plan and budget (time and dollars).

Usually the waterfall method is preferred, but some projects such as man-machine interfaces are seldom successful in the first go around. On the other hand, if the design is very expensive to build (think of suspension bridges or silicon wafer fabs), then the spiral method is too costly to be used.

Many "waterfall" projects actually use a hybrid approach, where a limited number of TBDs are allowed in the specification until after a prototype is built. The challenge is to know when to stop allowing TBDs to remain in the spec.

Deciding which method to use is important at the start of each project. If your company has a formal development methodology, it is likely to be based on the waterfall methodology. In that case, it is important to recognize which projects will have special needs for prototype testing.

Design projects that should use the spiral methodology include anything that is both inexpensive to prototype and/or requires human interface.

-Don Burtis