[The common definition of estimate is] "the most optimistic prediction that has a
non-zeroprobability of coming true." … Accepting this definition leads irrevocably toward a method called what's-the-earliest-date-by-which-you-can't- prove-you-won't-be-finished estimating
The inaccuracy of software project estimates—as muddied by
Tom DeMarco wrote his common definition of an estimate in 1982. Despite the successes I mentioned in the first chapter, not much has changed in the years since he wrote that definition. You might already agree that accurate estimates are
Managers and other project stakeholders sometimes fear that, if a project is overestimated, Parkinson's Law will kick in—the idea that work will expand to fill available time. If you give a developer 5 days to deliver a task that could be completed in 4 days, the developer will find something to do with the extra day. If you give a project team 6 months to complete a project that could be completed in 4 months, the project team will find a way to use up the extra 2 months. As a result, some managers consciously squeeze the estimates to try to avoid Parkinson's Law.
Another concern is Goldratt's "Student Syndrome" (Goldratt 1997). If developers are given too much time, they'll procrastinate until late in the project, at which point they'll rush to complete their work, and they probably won't finish the project on time.
The developers say that this project will take 6 months. I think there's some padding in their estimates and some fat that can be squeezed out of them. In addition, I'd like to have some schedule urgency on this project to force prioritizations among features. So I'm going to insist on a 3-month schedule. I don't really believe the project can be completed in 3 months, but that's what I'm going to present to the developers. If I'm right, the developers might deliver in 4 or 5 months. Worst case, the developers will deliver in the 6 months they originally estimated.
Are these arguments compelling? To determine that, we need to examine the arguments in favor of erring on the side of overestimation.
Reduced effectiveness of project plans
Low estimates undermine effective planning by feeding bad assumptions into plans for specific activities. They can cause planning errors in the team
If the estimation errors caused the plans to be off by only 5% or 10%, those errors wouldn't cause any significant problems. But numerous studies have found that software estimates are often inaccurate by 100% or more (Lawlis, Flowe, and Thordahl 1995; Jones 1998; Standish Group 2004; ISBSG 2005). When the planning assumptions are wrong by this magnitude, the average project's plans are based on assumptions that are so far off that the plans are virtually useless.
Statistically reduced chance of
Poor technical foundation leads to
Destructive late-project dynamics make the project worse than nominal
Once a project gets into "late" status, project
More status meetings with upper management to discuss how to get the project back on track.
Frequent reestimation, late in the project, to determine just when the project will be completed.
Apologizing to key customers for missing delivery dates (including
Preparing interim releases to support customer demos, trade shows, and so on. If the software were ready on time, the software itself could be used, and no interim release would be necessary.
More discussions about which requirements
Fixing problems arising from quick and dirty workarounds that were implemented earlier in response to the schedule pressure.
The important characteristic of each of these activities is that they don't need to occur at all when a project is meeting its goals. These extra activities drain time away from productive work on the project and make it take longer than it would if it were estimated and planned accurately.
Goldratt's Student Syndrome can be a factor on software projects, but I've found that the most effective way to address Student Syndrome is through active task tracking and buffer management (that is, project control), similar to what Goldratt suggests, not through biasing the estimates.
As Figure 3-1 shows, the best project results come from the most accurate estimates (Symons 1991). If the estimate is too low, planning
Figure 3-1: The penalties for underestimation are more severe than the penalties for overestimation, so, if you can't estimate with complete accuracy, try to err on the side of overestimation rather than underestimation.
I believe that Parkinson's Law does apply to software projects. Work does expand to fill available time. But deliberately
Don't intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates.