The design-to-schedule lifecycle model is similar to the staged-release lifecycle model in that you plan to develop the product in successive stages. The difference is that you don't necessarily know at the outset that you'll ever make it to the last release. You might have five stages planned—but only make it to the third stage because you have an immovable deadline. Figure 7-10 on the next page illustrates this lifecycle model.

This lifecycle model can be a viable strategy for ensuring that you have a product to release by a particular date. If you absolutely must have functioning software in time for a trade show, or by year's end, or by some other immovable date, this strategy guarantees that you will have something. This strategy is particularly useful for parts of the product that you don't want on the critical path. For example, The Microsoft Windows operating system includes several "applets," including WordPad, Paint, and Hearts. Microsoft might use design-to-schedule for those applets to keep them from delaying Windows overall.

Figure 7-10. Design-to-schedule model. Design-to-schedule is similar to the staged-release model and is useful when your system has a drop-dead delivery date.

As Figure 7-10 suggests, one of the critical elements of this lifecycle model is that you prioritize the features and plan your stages so that the early stages contain the highest-priority features. You leave the lower-priority features for later. If the ship date arrives before you've completed all the stages, you don't want to have to leave out critical features because you've spent time implementing less critical ones.

The primary disadvantage of this approach is that if you don't get through all of the stages, you will have wasted time specifying, architecting, and designing features that you don't ship. If you hadn't wasted time on a lot of incomplete features that you didn't ship, you would have had time to squeeze in one or two more complete features.

The decision about whether to use the design-to-schedule model comes down mostly to a question of how much confidence you have in your scheduling ability. If you're highly confident that you can hit your schedule targets, this is an inefficient approach. If you're less confident, this approach just might save your bacon.