Contents
9.1 Overly Optimistic Scheduling
9.2 Beating Schedule Pressure
Related Topics
Estimation: Chapter 8
50/50 scheduling: Odds of Completing on Time
Development-speed trade-offs: Development-Speed Trade-Offs
Commitment-based scheduling: Sections 2.5 and 8.5
Customer relations: Chapter 10
Theory-W management: Chapter 37
Voluntary overtime: Chapter 43
Summary of principled negotiation: Chapter 29
MY TEAM SPENT SEVERAL DAYS WORKING ON a detailed project estimate. (Yes, this is my experience—not a case study.) We divided the project into several dozen features, and each person estimated each feature individually. We spent two long days discussing the estimates feature by feature so that we fully understood the variability in each one. We considered several approaches to combining the individual-feature estimates, and we finally came up with a most-likely schedule estimate of 15 months and a range of 12 to 18 months.
To sanity-check our work, we estimated the new project's size as a percentage of a similar, previous project's size and calculated the new schedule from the old one. That estimate came out to 15 months. Then we pumped our numbers into a commercial estimating tool, and the tool estimated 16 months. Jones's first-order estimation practice spit out a 16-month estimate, too.
CROSS-REFERENCE
For details on first-order estimation practice, see Jones's First-Order Estimation Practice in Schedule Estimation.
On the way into the oversight committee meeting the next week, my boss asked, "What did your estimate come out to be?"
"15 months, plus or minus 3 months," I said.
"That's too long," he said. "I told you I wanted a short estimate. I'm going to tell the committee 9 months; that way, if we need some more time we can slide a little bit and still deliver in 12."
I protested. "Where did you get 9 months? We've already pared down the product in every way we can. That 15-month estimate is about as solid as estimates get. Nine months doesn't even make sense."
"To this committee, it does," my boss said sternly. By that time, other people on the committee were beginning to arrive, so I sat through the meeting and watched my boss sign me up for a schedule that I knew was impossible.
In the ideal world, you would create an estimate using practices such as those described in the previous chapter, and then you would be allowed to work to that schedule. In the real world, your boss, customer, marketing rep, or boss's boss can overrule your best estimate with a few waves of their magic wands and sign you up for an impossible deadline. But whether they know it or not, it's not in their best interest to underestimate your project.
What does scheduling have to do with rapid development? It has to do with creating an environment that isn't characterized by hasty, error-prone decision making and that is conducive to effective planning, thoughtful design, and time-saving quality assurance.
Creating an accurate, analytical estimate does not guarantee that the estimate will be accepted or that the project will actually be scheduled in a way that supports efficient development. Between current estimation practices and current scheduling practices, I am convinced that scheduling practices are the more serious problem.
The previous chapter described how to create an accurate estimate. This chapter discusses how to get that estimate accepted.
Although you might think of impossible schedules as a modern problem, overly optimistic software schedules are a shop-worn tradition in software development. In 1967, Gene Bylinsky reported that "all significant programming problems turn out to be emergencies" (Bylinsky 1967). In the 1970s, Fred Brooks pointed out that "more software projects have gone awry for lack of calendar time than all other causes combined" (Brooks 1975). A decade later, Scott Costello observed that "deadline pressure is the single greatest enemy of software engineering" (Costello 1984).
First Law of Bad Management: "When something isn't working, do more of it." | ||
| --Gerald Weinberg | ||
The situation hasn't changed in the 1990s. Capers Jones reports that excessive schedule pressure is the most common of all serious software engineering problems. "Excessive or irrational schedules are probably the single most destructive influence in all of software" (Jones 1991, 1994). Working under extreme deadline pressure has become a tradition. Fifty percent of projects set their schedules before requirements are set, and they don't set them with time to spare. It isn't uncommon for customers to insist on costs and schedules that are so far below U.S. norms that completion on time and within budget is technically impossible (Jones 1994).
This section examines the common practice of overly optimistic scheduling.
The development of Microsoft Word for Windows 1.0 provides an object lesson in the effects of optimistic scheduling practices. Word for Windows, aka "WinWord," spent 5 years in development, consumed 660 man-months of developer effort, and produced a system of 249,000 lines of code (Iansiti 1994). The final 5-year schedule was approximately five times as long as originally planned. Table 9-1 on the next page summarizes WinWord's scheduling history.
WinWord had an extremely aggressive schedule. The shortest possible schedule for a project of its size is about 460 days. The longest estimate for WinWord 1.0's schedule was 395 days, which is 65 days shorter than the shortest possible schedule.
CROSS-REFERENCE
See Table 8-8 for the full set of shortest possible schedules.
Development of WinWord 1.0 contained classic examples of the things that go wrong when a software project is scheduled too aggressively:
WinWord was beset by unachievable goals. Bill Gates's directive to the team was to "develop the best word processor ever" and to do it as fast as possible, preferably within 12 months. Either of those goals individually would have been challenging. The combination was impossible.
Table 9-1. Scheduling History of Word for Windows 1.0
Report Date
Estimated Ship Date
Estimated Days to Ship
Actual Days to Ship
Relative Error
Source: Adapted from "Microsoft Corporation: Office Business Unit" (Iansiti 1994).
Sep-84
Sep-85
365
1887[a]
81%
Jun-85
Jul-86
395
1614
76%
Jan-86
Nov-86
304
1400
78%
Jun-86
May-87
334
1245
73%
Jan-87
Dec-87
334
1035
68%
Jun-87
Feb-88
245
884
72%
Jan-88
Jun-88
152
670
77%
Jun-88
Oct-88
122
518
76%
Aug-88
Jan-89
153
457
67%
Oct-88
Feb-89
123
396
69%
Jan-89
May-89
120
304
61%
Jun-89
Sep-89
92
153
40%
Jul-89
Oct-89
92
123
25%
Aug-89
Nov-89
92
92
0%
Nov-89
Nov-89
0
0
0%
[a] This value is approximate.
Aggressive scheduling prevented accurate planning. As Table 9-1 shows, only one estimate was longer than a year, although at the times the estimates were made, ten estimates actually had more than a year to go. A 60- to 80-percent wishful-thinking factor remained a constant part of the schedule for the first 4 years of the project.
The project experienced extremely high turnover. It had four development leads in 5 years, including two who quit the project because of the schedule pressure and one who quit for medical reasons.
Because of schedule pressure, developers shortchanged their feature implementations, declaring them to be "done" even though they had low quality and were incomplete. The result was that WinWord spent 12 months in "stabilization," a period that had been expected to take only about 3 months.
Did WinWord's aggressive schedule help it to be delivered faster? No. Five years for a 250,000 line-of-code product isn't rapid development. In spite of its aggressive schedule, WinWord wasn't released in the time frame of even the nominal schedule for a project of its size. (The nominal schedule would have been 26 months.)
Should WinWord have been scheduled as a rapid-development project? Probably not. Innovation was more important than schedule speed on the WinWord project, and it should have been scheduled accordingly. If WinWord's project planners had planned WinWord as an "efficient" development project, they would have scheduled it to take about 22 months. That schedule would have been almost twice as long as the longest schedule actually planned for the project, but it would have relieved the pressure that caused development-lead turnover and excessive stabilization time.
It's painful to schedule a project for 22 months when you want to finish it in 12, but wishful thinking is no substitute for careful planning, and "wishin' don't make it so." The schedule that will produce the most rapid delivery is the most accurate one, and projects that practice wishful scheduling pay a schedule penalty of weeks or months for doing so. The WinWord 1.0 team paid its penalty in years.
CROSS-REFERENCE
In addition to the discussion in this chapter, for more on the value of accurate schedules, see Convergence Between Estimates and Reality in The Software-Estimation Story.
CROSS-REFERENCE
One kind of overly optimistic schedule is the kind that is handed to the developer with schedule, resources, and features already defined. For details, see Development-Speed Trade-Offs, "Development-Speed Tradeoffs."
The root causes of overly optimistic schedules are deep and manifold. Here are some of the causes:
There is an external, immovable deadline such as the date of a computer trade show, change in tax laws, or Christmas shopping season.
Managers or customers refuse to accept a range of estimates and make plans based on a single-point "best case" estimate.
Managers and developers deliberately underestimate the project because they want a challenge or like working under pressure.
The project is deliberately underestimated by management or sales in order to submit a winning bid.
Developers underestimate an interesting project in order to get funding to work on it.
The project manager believes that developers will work harder if the schedule is ambitious and therefore creates the schedule accordingly.
Top management, marketing, or an external customer want a particular deadline, and the project manager can't talk them out of it.
The project begins with a realistic schedule, but new features are piled on to the project, and before long the project is running under an overly optimistic schedule.
The project is simply estimated poorly.
With this many sources of optimistic schedules, it's amazing that any realistic schedules are created at all.
If you want to complete your project in the shortest possible time, it seems as though it would make sense to set a short schedule. It seems rational to think that even if you don't quite meet the short schedule, you might deliver the project earlier than you would have otherwise. You can exhort a person digging a ditch to shovel faster. Can't you exhort software developers to design and code faster?
As intuitively appealing as this simplistic argument is, it doesn't work in software. (And it probably doesn't work in ditch-digging either.) Why doesn't it work? Here are the reasons.
Schedule accuracy. The first reason that optimistic scheduling doesn't work is that using an overly optimistic schedule reduces schedule accuracy. If you schedule in the middle of the schedule curve, you'll have a 50/50 chance of making your deadline. But it's difficult to schedule for a 50/50 chance of on-time completion. Programmers tend to underestimate their projects by 20 to 30 percent (van Genuchten 1991). As Figure 9-1 shows, if you use the developers' estimates as a baseline, you'll already be estimating on the left side of the curve—that is, with a less than 50-percent chance of completing your project on time.
CROSS-REFERENCE
For more on 50/50 scheduling, see Odds of Completing on Time, Odds of Completing on Time.
Figure 9-1. Typical developer schedule. Developers typically estimate 20 to 30 percent lower than their actual effort. Merely using their normal estimates puts the chance of completing on time below 50 percent.
Merely using the developer's "most likely" estimates gives you less accuracy than you would like. If you go beyond that to an optimistic estimate (as shown in Figure 9-2), you'll have little or no chance of delivering your product on time.
Figure 9-2. Typical optimistic schedule. People sometimes think that setting a shorter schedule will increase the chance of early delivery, but all it really does is reduce accuracy and increase the chance of being late.
Quality of project planning. An overly optimistic schedule undermines effective planning by feeding bad assumptions into phase planning, staffing-level planning, staff selection, staff-buildup planning, module-development planning, integration planning, test planning, and documentation planning. It would be convenient if plans would work when they are based on faulty assumptions; then we could use the same plans on every project! Unfortunately that doesn't happen, and faulty assumptions result in ineffective project plans. (See Figure 9-3 on the next page.)
Overly optimistic schedules don't result in plans that are off by just a little bit. The average small-project estimate is off by more than 100 percent (Standish Group 1994). The average large project is a year late (Jones 1994). With errors of this magnitude, the average project is doing planning that's virtually useless.
Adherence to plan. Even when planning is done effectively in the first place, a characteristic of all but the most sophisticated software organizations is that they throw out their plans and run free-form when they get into schedule trouble (Humphrey 1989). Setting an optimistic, unachievable schedule increases the risk that a project will run without a plan.
Underscoping the project. An overly optimistic schedule can cause you to spend too little time on the upstream activities of requirements analysis and design. On a well-run project, you'll typically spend about one-third of your time on design. On a 12-month project, you would spend 4 months on design. If you estimated a 12-month project to take 6 months and planned design time accordingly, you would plan for only 2 months of design work, half of what you should plan for. It's already difficult enough to know whether you've done a good job on requirements and design—to know whether you're really done—and a short schedule encourages you not to think about it very hard. The usual effect of a short schedule is that the project rushes through requirements and design, either not completing the work or doing it sloppily. Those activities are inadvertently shortchanged.
Whatever you put into the project upstream, you get to fish out of the project downstream. Downstream from the shortchanged requirements and design, you'll fish out extra testing, defect correction, redesign, and rework—at anywhere from 10 to 100 times what it would have cost if it had been done properly in the first place (Fagan 1976, Boehm and Papaccio 1988).
Officials from Loral admitted that their problems on the FAA's Advanced Automation System—which in 1994 was more than 5 years late and a billion dollars over budget—resulted from shortchanging their standard development processes in trying to meet the customer's unrealistic schedule demands. Time-to-market is greatly affected by the compromises a project inevitably makes when it sets an unachievable schedule (Curtis 1994).
Project focus. In addition to its effects on technical work, an overly optimistic schedule can divert managers away from activities that move the project forward. After the project fails to meet its initial delivery date, the project manager's efforts are diverted into "schedule politics" and into explaining how long the project will really take and why the new schedule is more reliable than the original one. Each time a project misses a deadline, it typically goes through a rescheduling exercise, and that saps developers' time too.
Customer relations. Benjamin Franklin said that he would rather be a pessimist than an optimist; as a pessimist he would be pleasantly surprised more often. On the customer-relations side, when a project starts to look as though it won't meet its optimistic delivery date, customers, managers, and end-users are unpleasantly surprised. They naturally assume that the project is in trouble or out of control, even if it really is running smoothly. Once again, the project manager's attention is diverted from managing the project to managing the relationship with the customer, and the developer's attention is diverted from doing real work that moves the project forward to generating signs of progress to reassure the customer.
CROSS-REFERENCE
For more on customer relations, see Chapter 10, Chapter 10.
Over the long haul, optimistic scheduling erodes the relationship with the customer because customers lose faith in overly optimistic managers and developers.
Premature convergence. Any sculptor will tell you that you don't start polishing a stone carving until you've roughed in the shape you want. Any home builder will tell you that there's no point in putting up wallboard and wallpaper until the electricity, plumbing, and heating and cooling systems are in place. Any software developer will tell you that there is no point in creating a shippable version of a software product until the product is feature-complete and stable. And yet that's exactly what's done when you work under an overly optimistic schedule.
If you're working on a project that's supposed to take about a year, 8 to 12 weeks before you're scheduled to ship the product you'll launch a major effort to prepare the product for release. You'll perform time-consuming activities that you ordinarily do not do until just before the product ships:
Turning off debugging aids in the code
Performance-tuning the product
Removing or turning off partially implemented features that can't be completed in time to ship the product
Implementing quick-and-dirty versions of features that absolutely must be completed in time to ship the product
Fixing low-priority defects
Polishing help files and user documents by checking spelling, coordinating page numbers between different source files, inserting exact cross-references and online help jumps, creating indexes, taking final screen shots, and so on
Performing end-to-end system tests of the entire product and formally entering defects into the defect-reporting system
I think of these activities as forcing the product to converge. When a project tries to force convergence too early, it will fail to converge, and then it has to do all of those time-consuming activities again later.
Doing activities twice when they could be done once is inefficient. But there are other time-wasting aspects of premature convergence, too. If software is released to testing before it is ready, testers will find many more defects than they would find if it were not released until it was ready. When testers find more defects, they enter the defects into a formal bug-tracking system, which adds overhead that takes both testing and development time. Debugging aids have to be turned back on. Removed features have to be put back in. Quick-and-dirty "ship mode" changes that aren't reliable or maintainable come back to haunt the developers. To repeat, premature convergence is a waste of time.
Perhaps worse for the project is the effect that premature convergence has on developer morale. If you're running a foot race, when the gun goes off for the last lap, you'll give it your all. You want to arrive at the finish line with nothing left. With premature convergence, the gun goes off, you give it your all, and just before you reach the finish line someone moves it. That wasn't the last lap after all, but you're left with nothing more to give. In the long run, pacing is important, and premature convergence burns out developers too early.
Poorly managed projects often discover their schedule problems for the first time when their developers aren't able to force convergence. Better managed projects detect schedule problems much earlier. Symptoms of premature convergence include:
Developers can't seem to fix defects without tearing the system apart; small changes take longer than they should.
Developers have long lists of "trivial" changes, which they know they need to make but which they haven't made yet.
Testers find defects faster than developers can correct them.
Defect fixes generate as many new defects as they correct.
Tech writers have trouble completing user documentation because the software is changing too fast to be able to document it accurately.
Project estimates are adjusted many times by similar amounts; the estimated release date stays 3 weeks away for 6 months.
After you can't force convergence the first time, you'll need to back up, continue working, and try again to converge later. Optimistic schedules lead to premature and multiple attempts to converge, both of which lengthen schedules.
Customers' and managers' first response when they discover they aren't meeting their optimistic schedule is to heap more schedule pressure onto the developers and to insist on more overtime. Excessive schedule pressure occurs in about 75 percent of all large projects and in close to 100 percent of all very large projects (Jones 1994). Nearly 60 percent of developers report that the level of stress they feel is increasing (Glass 1994c).
Schedule pressure has become so ingrained in the software-development landscape that many developers have accepted it as an unalterable fact of life. Some developers are no longer even aware that the extreme schedule pressure they experience could be otherwise. That is unfortunate. Overly optimistic scheduling hurts the real development schedule in many ways, but excessive schedule pressure hurts it the most, so I want to explore this particular problem in detail.
Quality. About 40 percent of all software errors have been found to be caused by stress; those errors could have been avoided by scheduling appropriately and by placing no stress on the developers (Glass 1994c). When schedule pressure is extreme, about four times as many defects are reported in the released product as are reported for a product developed under less extreme pressure (Jones 1994). Excessive schedule pressure has also been found to be the most significant causative factor in the creation of extremely costly error-prone modules (Jones 1991).
CROSS-REFERENCE
For more on error-prone modules, see "Error-prone modules" in Quality-Assurance Fundamentals.
With extreme schedule pressure, developers also increase the subtle pressure they put on themselves to focus on their own work rather than on quality-assurance activities. Developers might still hold code reviews, for example, but when they are faced with a choice between spending an extra hour reviewing someone else's code or working on their own routines, the developers usually will choose to spend the extra hour on their own code. They'll promise themselves to do better on the code review next time. Thus, quality starts its downward slide.
CROSS-REFERENCE
For more on the relationship between defect-level and schedule, see Quality-Assurance Fundamentals, Quality-Assurance Fundamentals.
Projects that aim from the beginning at having the lowest number of defects usually also have the shortest schedules. Projects that apply excessive schedule pressure and shortchange quality are rudely awakened when they discover that what they have really shortchanged is the schedule.
Gambling. Since an overly optimistic schedule is impossible to achieve through normal, efficient development practices, project managers and developers are provided with an incentive to gamble rather than to take calculated risks. "I doubt that the Gig-O-Matic CASE tool will really improve my productivity by a factor of 100, but I have absolutely no chance of meeting my schedule without it, so what do I have to lose?"
CROSS-REFERENCE
For details on the occurrence of gambling on rapid-development projects, see Risk, High Risk, and Gambling, Risk, High Risk, and Gambling.
On a rapid-development project, you should be doing everything possible to reduce risk. Software projects require you to take calculated risks but not close-your-eyes-and-hope-that-it-works risks. Schedule pressure contributes to poor risk management and mistakes that slow development.
Motivation. Software developers like to work. A little bit of schedule pressure resulting from a slightly optimistic but achievable schedule can be motivating. But at some point the optimistic schedule crosses the threshold of believability, and at that point motivation drops—fast.
CROSS-REFERENCE
For more on schedule pressure and motivation, see Chapter 11, Chapter 11, and Organization of Best-Practice Chapters, Using Voluntary Overtime.
An overly optimistic schedule sets up developers to put in Herculean efforts only to be treated as failures for not achieving an impossible schedule—even when they have achieved a schedule that is nothing short of remarkable. The developers know this, and unless they are very young or very naive, they will not work hard—they will not commit, they will not "sign up"—to achieve a schedule that is out of reach. Anyone who tries to motivate by forcing commitment to an unachievable schedule will achieve exactly the opposite of what is desired.
Creativity. Many aspects of software development—including product specification, design, and construction—require creative thought. Creativity requires hard thinking and persistence when the sought-after solution doesn't immediately spring to mind. The drive to think hard and persist requires internal motivation. Excessive external motivation (aka stress) reduces internal motivation and in turn reduces creativity (Glass 1994a).
Aside from reducing the incentive to be creative, a pressure-cooker environment is simply the wrong kind of environment for creative thought. The cogitation required for a breakthrough solution requires a relaxed, contemplative state of mind.
Given the same set of requirements, developers will create solutions that vary by as much as a factor of 10 in the amounts of code they require (Sackman, Erikson, and Grant 1968; Weinberg and Schulman 1974; Boehm, Gray, and Seewaldt 1984; De Marco and Lister 1989). If you're on a rapid-development schedule, you can't afford to create a pressure-cooker environment in which people are too rushed to find the solution that is one-tenth as expensive to implement as the others.
Burnout. If you use too much overtime in one project, your developers will more than make up for it on the next project. Programmers will putter around for months after putting in a big push on a major project—cleaning up their file systems, slowly commenting their source code, fixing low-priority bugs that they find interesting but which were not important enough to fix for the release (and may not be important enough to fix now), playing ping-pong, organizing their email, fine-tuning design documents, reading industry publications, and so on. If your schedule pushes developers too hard (perhaps by trying to force a premature convergence), you can experience that burnout on your current project rather than the next one.
Turnover. Overly optimistic schedules and the accompanying schedule pressure tend to cause extraordinarily high voluntary turnover, and the people who leave the project tend to be the most capable people with the highest performance appraisals (Jones 1991). Finding and training their replacements lengthens the schedule.
Long-term rapid development. Excessive overtime eliminates the free time that developers would otherwise spend on professional development. Developers who don't continue to grow don't learn about new practices, and that hurts your organization's long-term rapid-development capacity.
Relationship between developers and managers. Schedule pressure widens the gap between developers and managers. It feeds the existing tendency developers have to believe that management doesn't respect them, management doesn't care about them, and management doesn't know enough about software development to know when they're asking for something that's impossible. (See Figure 9-4.) Poor relationships lead to low morale, miscommunication, and other productivity sinkholes.
Some people seem to think that software projects should be scheduled optimistically because software development should be more an adventure than a dreary engineering exercise. These people say that schedule pressure adds excitement.
How much sense does that make? If you were going on a real adventure, say a trip to the south pole by dogsled, would you let someone talk you into planning for it to take only 30 days when your best estimate was that it would take 60? Would you carry only 30 days' worth of food? Only 30 days' worth of fuel? Would you plan for your sled dogs to be worn out at the end of 30 days rather than 60? Doing any of those things would be self-destructive, and underscoping and underplanning a software project is similarly self-destructive, albeit usually without any life-threatening consequences.
In Quality Software Management, Gerald Weinberg suggests thinking about software projects as systems (Weinberg 1992). Each system takes in inputs and produces outputs. The system diagram for a project that's been accurately scheduled might look like the picture in Figure 9-5.
Figure 9-5. System diagram for a project with an accurate schedule. Most people will be happy with the outputs from an accurately-scheduled project.
The system diagram for a project that's been scheduled overly optimistically will, unfortunately, look more like the picture in Figure 9-6.
Figure 9-6. System diagram for a project with an overly optimistic schedule. Most people won't like the outputs from a project with an overly optimistic schedule.
When you compare the two systems, you can see that one is markedly healthier than the other.
In the end, I am opposed to the practice of overly optimistic scheduling because it undermines effective planning, eats into developers' personal lives, erodes relationships with customers, contributes to high turnover, contributes to low quality, and hurts the industry by stunting professional growth and creating the perception that software developers can't deliver what they promise.
But I am most opposed to overly optimistic scheduling because it doesn't work. It doesn't result in shorter actual schedules; it results in longer ones. That's what happened with WinWord 1.0. That's what happened with the FAA's Advanced Automation System. That's what happened with every other project I know of that has tried to work to an impossible schedule.
If you are not outraged, you are not paying attention. | ||
| --Bumper sticker | ||
The shortest actual schedule results from the most accurate planned schedule. A project that has schedule problems needs to look no further for the source of its problems than an unachievable initial schedule.