Suppose that six months from now you plan to move to a new town 100 miles away and build a new house. You arrange with Honest Abe's Construction Company to construct the house for you. You agree to pay Abe $100,000, and Abe agrees to have the house ready in six months so that you can move into it when you move to town. You've already bought the site, and Abe agrees that it's suitable. So you shake hands, pay him half the money as a down payment, and wait for your house.
After a few weeks, you get curious about how work on the house is going, so one weekend you drive the 100 miles to the site to take a look at it. To your surprise, all you see at the site is an area where the dirt has been leveled. No foundation, no framing, no other work at all. You call Honest Abe and ask, "How's the work on my house going?" Abe says, "We're getting kind of a slow start because of another house that we've been finishing. I built some slack into my estimate for your house, though, so there's nothing to worry about."
Your job gets busy again, and by the time you have a chance to look at your house's progress again, three months have passed. You drive to the site again, and this time the foundation has been poured, but no other work is visible. You call the contractor, who says, "No problem. We're right on schedule." You're still nervous, but you decide to take Abe's word for it.
The fourth and fifth months go by. You call Abe a few times to check on progress, and each time he says it's going great. At the beginning of the sixth month, you decide to drive to look at the house one more time before it's finished. You're excited to see it. But when you get to the site, the only thing you see is the frame for the house. There's no roofing, siding, plumbing, wiring, heating, or cooling. You're nervous and tense, and you decide to check some of Honest Abe's references. You find that once in a while Abe has managed to complete a house when promised, but most of the time his houses are anywhere from 25 percent to 100 percent late. You're irate. "We're five months into a six-month schedule, and you hardly have anything done," you growl at him. "When am I going to get my house? I need to move into it a month from now." Abe says, "My crew is working as hard as possible. You'll get your house on time. Trust me."
Do you decide to trust Abe? Of course not! Not with his track record and the progress you've seen so far.
Yet in similar cycles in software development—with similar time frames and even larger amounts of money—we expect our customers to want less in the way of signs of progress than we would expect from someone building a house for us. We expect them to sign off on a set of requirements and then just sit tight for weeks or months or even years before we have anything tangible to show them. No wonder customers get nervous! No wonder customers think that software development takes a long time!
Even if you're completely on schedule, be aware that the perception of slow development can affect your project as much as the reality. Even though we do it all the time, it's unreasonable to expect customers to sit tight for months on end, and it's part of our job to provide them with steady signs of progress.
Sometimes overcoming the perception of slow development requires more than providing steady signs of progress. Most of today's projects are scheduled in the rapid or impossible zones. Most projects lack the planning and resource commitments needed to meet their aggressive schedules. The project planners often do not even realize just how ambitious their schedules are, and, as Figure 6-9 suggests, they are usually completed in the slow zone.
CROSS-REFERENCE
For details on problems associated with unrealistic schedules, see Overly Optimistic Scheduling, Overly Optimistic Scheduling.
Figure 6-9. Typical planning in relation to the software-schedule curve. Because of unrealistic expectations, most projects will be perceived as slow even if they are completed in the efficient or rapid zones.
The gap between the scheduled completion date and the actual completion date accounts for much of the perception that software projects are slow. If the average project is scheduled in the impossible zone but staffed and completed in the efficient zone, people will consider it to have failed even though its developers have completed it efficiently and might actually have completed it as quickly as possible given the resources provided.
In general terms, you can overcome the problem of slow development in either of two ways:
Address the reality of slow development. Make the actual schedules shorter by moving from slow development to efficient development or by moving from efficient development to rapid development.
Address the perception of slow development. Eliminate wishful thinking, and make planned schedules more realistic by lengthening them to close the gap between planned and actual completion dates. Use practices that highlight progress visibility. Sometimes customers don't want increased development speed as much as they just want you to keep them informed.
The development speed zone you're in currently will determine whether you should focus on slow development itself or on the perception of slow development. Most often, you'll need to address the problem on both levels.