Rapid Development: Taming Wild Software Schedules. Redmond, Wa.: Microsoft Press, 1996. 660 pages. Retail price: $35. ISBN: 1-55615-900-5. Available from Microsoft Press 1-800-MS-PRESS (1-800-677-7377). Buy Rapid Development from Amazon.com.

What Kind of Rapid Development Do You Need? 

The most central issue to the topic of rapid development is determining what kind of rapid development you need. Do you need a slight speed edge, more predictability, better progress visibility, lower costs, or more speed at all costs?

One of the most surprising things I've discovered while doing the background research for this book is that many people who initially say they need faster development find that what they really need is lower cost or more predictability--or just to avoid a catastrophic failure.

You can ask several questions to help determine what kind of rapid development you need:

• How strong is the product's schedule constraint?
• Does the project's emphasis on schedule arise because it is really one of the common rapid-development lookalikes?
• Is your project limited by any weaknesses that would prevent a rapid-development success?

The following sections describe how to answer these questions.

Products with Strong Schedule Constraints

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-2 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-2. 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 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 have to make a payroll system change in time to comply with a change in 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 take in twice as much revenue if you can beat your competitor to market by six weeks instead of releasing your product two 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.

Rapid-Development Lookalikes

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 that those things are not the same as out-and-out development speed.

Before you orient your project toward shortest schedule rather than least cost, lowest risk, or best functionality, find out what's really needed. There are several rapid-development lookalikes that appear to call for all-out development speed but really call for something else.

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 lookalike 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 is another tip off. The real demand in this case is not so much for faster development as for 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 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 tradeshow, they are probably more concerned about predictability than out-and-out development speed. 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-2, 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."

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-3 shows two possibilities.

Figure 6-3. 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 instead of focusing on speed-oriented practices.

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 at all of completing the project on time.

Desire for free overtime. In a few instances, the customer's (or manager's) interest in rapid development hides a desire to improve its 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 lookalike 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 tradeoffs in order 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 its 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 the 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.

So, Is All-Out Rapid Development Really What You Need?

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.

Beware 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 three. 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 but 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 knock-out product; the late delivery won't matter as much then 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 the one with the strong schedule constraint in Figure 6-2. 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 quick deliveries of 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 Word for Windows 1.0 was originally scheduled to take one year and took five (Iansiti 1994). Windows 95 was delivered one and one-half years later than originally announced and became the fastest-selling product in software history. One financial product that I worked on was delivered 50 percent later than originally scheduled but went on to become the most popular product in the 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 development schedule was critically important at the time.

This material is Copyright © 1996 by Steven C. McConnell. All Rights Reserved.