Throwaway Prototyping is usually successful. Nonetheless, you should address several risks when planning a project that will use it.

Keeping a throwaway prototype. One of the key problems in developing a throwaway prototype is that the prototype might not get thrown away. Managers often decide after the prototype has been developed that it will cost too much to "redo" the system and insist on evolving the prototype into the final product (Gordon and Bieman 1995).

Avoid this trap! Delivering a throwaway can result in poor design, poor maintainability, and poor performance. If you plan to develop a throwaway prototype, be sure that managers and technical staff both commit to throwing it away. Be sure that everyone understands that you are creating disposable software that isn't robust enough to be put into production or strong enough to serve as a foundation for the final product. You are not creating real software.

If you think that you might evolve the prototype rather than throw it away, plan from the outset to use an evolutionary approach so that the prototype's design and implementation will support full development.

As for the objection that throwing away the prototype costs too much, done right, the reason you create a throwaway prototype is that it is cheaper to develop a throwaway prototype, learn lessons the cheap way, and then implement the real code with fewer mistakes than it is not to create the throwaway prototype in the first place. If you can think of some other method that will be more cost effective in a specific situation, use that instead. Otherwise, far from creating extra costs, Throwaway Prototyping is the most cost-effective practice available.

Inefficient use of prototyping time. As with Evolutionary Prototyping, projects often waste time during Throwaway Prototyping and unnecessarily lengthen the development schedule. Although prototyping is by nature an exploratory process, that does not mean that it has to be an open-ended process.

Monitor prototyping activities carefully. Treat each throwaway prototype as an experiment. Develop a hypothesis such as, "A disk-based merge-sort will sort 10,000 records in less than 30 seconds." Then be sure that the prototyping activity stays focused on proving or disproving the hypothesis. Don't let it stray off into related areas, and make sure that the prototyping stops as soon as the hypothesis has been proved or disproved.

Unrealistic schedule and budget expectations. As with other kinds of prototyping, when users, managers, or marketers see rapid progress on a prototype, they sometimes make unrealistic assumptions about how quickly the final product can be developed. The time required to move from a throwaway-prototype implementation to implementation in the target language is sometimes grossly underestimated.

The best way to combat this risk is to estimate the development of the prototype and the development of the final product as separate projects.