Although there are a few similarities, Staged Delivery is not a form of prototyping. Prototyping is exploratory, and Staged Delivery is not. Its goal is to make progress visible or to put useful software into the customers' hands more quickly. Unlike prototyping, you know the end result when you begin the process.

If the Staged Delivery practice provides less flexibility than you need, you can probably use Evolutionary Delivery (Chapter 20) or Evolutionary Prototyping (Chapter 21) instead. If your customers get the stage 1 release and tell you that what you're planning to deliver for stage 2 won't suit them, you'd have to be pigheaded not to change course. If you know the general nature of the system you're building but still have doubts about significant aspects of it, don't use Staged Delivery.

Staged Delivery combines well with Miniature Milestones (Chapter 27). By the time you get to each stage, you should know enough about what you're building to map out the milestones in detail.

Success at developing a set of staged deliveries depends on designing a family of programs (Define Families of Programs in Using Designing for Change). The more you follow that design practice, the better able you'll be to avoid disaster if the requirements turn out to be less stable than you thought.