Products that truly need to focus on all-out development speed rather than cost or predictability have a different time-value curve than typical products have. As the value line for a typical product in Figure 6-3 shows, the value of a typical product declines gradually as time goes by. But with a product that has a strong schedule constraint, there is a point at which the value of the product declines precipitously.

Figure 6-3. Depiction of value over time for typical products and products with strong schedule constraints. There isn't as much urgency to complete a typical product by any particular date as there is for a product that has a strong schedule constraint.

For a typical product, efficient development usually provides the best combination of development cost and schedule performance. But maybe your product must be ready in time for the Christmas sales season or you'll have to wait another year. Maybe you need to make a payroll-system change in time to comply with a new tax law. Maybe your company is about to go under financially, and you need the revenue from the product to save the company. Or maybe you need to leapfrog a competitive product, and you stand to double your revenue if you can beat your competitor to market by 6 weeks instead of releasing your product 2 weeks after they do.

As the graph suggests, on these projects there may be a point by which, if you haven't released your product, you might as well not have developed it at all. In these cases, a focus on all-out development speed can be appropriate.

In some instances the demand for "rapid development" comes via a circuitous path from users or customers or upper management. They can apply an incredible amount of pressure to get a product done fast, but sometimes they really want lower cost or less risk instead. They just don't know how to ask for those things—or don't know that those things do not go hand in hand with all-out development speed.

Before you orient your project toward the shortest schedule rather than the least cost, lowest risk, or best functionality, find out what's really needed. Several rapid-development look-alikes appear to call for all-out development speed but really call for something else; these are discussed in the following subsections.

Runaway prevention. If the software organization has a history of overshooting its planned schedules and budgets, the customer might ask for "rapid development." But in this case, what the customer really wants is assurance that the project will be completed close to its target schedule and budget.

You can distinguish this rapid-development look-alike from a need for all-out development speed either by realizing that there's no specific schedule goal other than "as soon as possible" or, if there is a specific goal, by finding that no one can explain why it matters. A history of runaway projects can be another tip-off. The solution in this case is not the use of schedule-oriented practices but rather the use of better risk management, project estimation, and management control.

Predictability. In many instances, customers want to coordinate the software-development part of a project with revenue projections, marketing, personnel planning, and other software projects. Although they might call for "rapid development," they're really calling for predictability good enough to let them coordinate related efforts. If your customers emphasize the need to complete the software "on time" and don't have an external constraint such as a trade show, they are probably more concerned about predictability than out-and-out development speed. In that case, focus on efficient development, and emphasize practices that reduce schedule risk.

Lowest cost. It isn't uncommon for customers to want to minimize the cost of a software-development project. In such cases, they will talk about getting the software done quickly, but they will emphasize their budget concerns more than their schedule concerns.

If the customers' primary concern is the cost of a project, a focus on development schedule is particularly unfortunate. Although it's logical to assume that the shortest development schedule is also the cheapest, in actuality the practices that minimize cost and schedule are different. Lengthening the schedule somewhat beyond the nominal schedule and shrinking the team size can actually reduce the total cost of a project. Some rapid-development practices increase the total cost.

Fixed drop-dead date. As shown in Figure 6-3, sometimes the value of a product declines steadily over time, and sometimes it declines precipitously after a certain point. If there is a point at which it declines precipitously, it seems logical to say that: "We need all-out development speed so that we can be sure to release the product by that point."

But whether you need rapid development really depends on how much time you have to do the project and how much time it would take to develop the project using efficient-development methods. Figure 6-4 shows two possibilities.

Figure 6-4. Whether you need to use rapid-development practices depends on how soon you need the software. If you can develop it in Time Frame 1 by using efficient-development practices, you should do that and keep risks low instead of focusing on speed-oriented practices that can increase risk.

If you can complete the project in Time Frame 1 (before the drop-dead date) by using efficient-development practices, then do that—and focus on risk-reduction rather than development speed. That will provide the greatest likelihood of completing the project on time. Some rapid-development practices reduce development time but also increase schedule uncertainty, and it would be a mistake to use practices that increase schedule risk in this situation.

If efficient-development practices alone aren't capable of completing the project before the drop-dead date—for example if they are capable only of completing the project in Time Frame 2—then you'll need to use speed-oriented practices to have any chance of completing the project on time.

Desire for free overtime. In a few instances, the customer's (or manager's) interest in rapid development masks a desire to improve rapid development's bottom line by eking out as much unpaid overtime as possible. The sense of urgency created by an ambitious schedule helps to do that.

This look-alike is easy to distinguish from true rapid development because the customer will stress the importance of the schedule and simultaneously refuse to provide the support needed to improve development speed through any means other than unpaid overtime. The customer won't kick in for more developers, improved hardware tools, improved software tools, or other kinds of support. The customer won't be willing to make feature-set trade-offs to achieve schedule goals. On a true rapid-development project, the customer will be eager to consider any and all means of shortening the schedule.

If meeting the project's schedule is important enough to put pressure on you, it is important enough for the customer to increase the level of support for the project. If the company asks its developers to work harder, it must be willing to work harder, too. If you find yourself in a situation in which your customer is simply trying to get your team to work for free, there is probably almost nothing that you can do to improve it. Customers who practice this style of software development do not have your best interests in mind. Your most sensible options are to refuse to work on such projects or to change jobs.

It's a fact of life that customers—including end-users, marketers, managers, and others—will always clamor for new features and new releases. But customers are also aware of the disruption that a product upgrade can cause. Be aware that customers expect you to balance product, cost, and schedule for them. Of course, they will request that you provide a great product at low cost on a short schedule, but you usually get to pick only two out of these three desires. Releasing a low-quality product on a short schedule is usually the wrong combination. If you release a low-quality product on time, people will remember that it was low-quality—not that it was on time. If you release a late product that knocks their socks off, your customers will remember that you released a knockout product; in retrospect, the late delivery won't matter as much as it seems to now.

To determine whether customer requests justify an all-out rapid-development effort, try to determine whether the value line of your product looks more like the typical product or like products with strong schedule constraint shown in Figure 6-3. Find out whether an external date is driving the schedule or whether the date is really just "as soon as possible." Finally, find out whether top management will provide the level of support you'll need for a rapid-development effort. There's little point in going all out if you have to do it on your own.

If you're not sure that development speed occupies top priority, take your time and develop software you can be proud of. Develop a program that's worth waiting for; high-quality products are harder to compete with than are quickly delivered mediocre products.

The history of the microcomputer software industry is replete with examples of products that were delivered late but went on to achieve immense popularity. The development of Microsoft Word for Windows 1.0 was originally scheduled to take one year and took five (Iansiti 1994). Microsoft Windows 95 was delivered 1½ years later than originally announced (Cusumano and Selby 1995) and became one of the fastest-selling products in software history. One financial product that I worked on was delivered 50 percent later than originally scheduled by its company but went on to become the most popular software product in that company's 25-year history. For each of these products, timely release (as originally defined) was not a key factor, even though everyone thought that the development schedule was critically important at the time.