Chapter 9—Scheduling
9.1 OVERLY OPTIMISTIC SCHEDULING
Excessive or irrational schedules are probably the single most destructive influence in all of software.
A. Root Causes of Overly Optimistic Schedules
1. There is an external, immovable deadline.
2. Managers or customers refuse to accept a range of estimates and make plans based on a single-point “Best
case” estimate.
3. Managers and developers deliberately underestimate the project because they want a challenge or like working
under pressure.
4. Management or sales deliberately underestimate the project in order to submit a winning bid.
5. Developers underestimate an interesting project in order to get funding to work on it.
6. The project manager believes that developers will work harder if the schedule is ambitious and therefore creates
the schedule accordingly.
7. Top management, marketing, or an external customer want a particular deadline, and the project manager can’t
talk them out of it.
8. 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.
9. The project is simply estimated poorly.
B. Effects of Overly Optimistic Schedules
If you want to complete your project in the shortest possible time, it seems to make sense to set a short schedule—it
doesn’t work.
1. Schedule accuracy—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. If you go
beyond that to an optimistic estimate, you’ll have little or no chance of delivering your product on time.
2. Quality of project planning—an overly optimistic schedule undermines effective planning by feeding bad
assumptions into your plans.
3. Adherence to plan—setting an optimistic, unachievable schedule increases the risk that a project will run
without a plan.
4. 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 wee-run project, you’ll typically spend about
one-third of your time on design.
The usual effect of a short schedule is that the project rushes through requirements and design.
5. Project focus—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”.
6. Customer relations—when a project starts to look as though it won’t meet its optimistic delivery date,
customers, managers, and end-users are unpleasantly surprised. 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 move the project forward to generating signs of progress to reassure the
customer.
7. Premature convergence—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.
There is no point in creating a shippable version of a software product until the product is feature-complete
and stable. Eight to twelve weeks before you are scheduled to ship the product, you’ll launch a major effort to
prepare the product for release, this is called convergence.
C. Excessive Schedule Pressure
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.
1. Quality—About 40 percent of all software errors have been found to be caused by stress. When schedule
pressure is extreme, about four times as many defects are reported.
2. Gambling—schedule pressure contributes to poor risk management.
3. Motivation—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 the point
motivation drops—fast. Developers will not “sign up” to achieve a schedule that is out of reach.
4. Creativity—requires hard thinking and persistence. Excessive stress reduces internal motivation and in turn
reduces creativity.
5. Burnout—if you use too much overtime in one project, your developers will more than make up for it on the next
project. If your schedule pushes developers too hard, you can experience that burnout on your current project
rather than the next.
6. Turnover—overly optimistic schedules tend to cause extraordinarily high voluntary turnover.
7. Long-term rapid development—excessive overtime eliminates the free time that developers would otherwise
spend on professional development.
8. Relationship between developers and managers—schedule pressure widens the gap between developers and
managers.
D. The Bottom Line
Accurate schedules results in
 On-time project
 High-quality product
 Happiness and satisfaction
 More loyalty
 Greater individual development skills
 Increased respect among all project participants
 Experience releasing software on time
Overly optimistic schedule and schedule pressure results in
 Late project
 Low-quality product
 Stress
 Disgruntled, cynical developers
 Higher turnover
 Strained relations among all project participants
 Weakened capacity to develop the next product
The shortest actual schedule results from the most accurate planned schedule.
9.2 BEATING SCHEDULE PRESSURE
Three factors converge to make up the bulk of the problems associated with setting software schedules
1. Wishful thinking—most software projects are ambitious, not average.
2. Little awareness of the software estimation story or the real effects of overly optimistic scheduling—software can’t
be reliably estimated in its early stages. It’s logically impossible.
3. Poor negotiating skills—developers were fairly good at estimating but poor as defending their estimates.
Principled Negotiation
1. Separate the people from the problem
DO:
 Work to improve the relationship with you manager or customer.
 Be cooperative.
 Work to set realistic expectations.
 Be sure that everyone understands the software-estimation story
 Be an advisor on schedule matters, and avoid slipping into the role of adversary.
 Suggest ways to change the project that will reduce the schedule, but hold firm to not just writing down a
different date.
2. Focus on interests, not positions
Positions are bargaining statements that are so narrow that in order for one person to win, the other person has to
lose. Underlying interests are broader than bargaining positions, and focusing on them opens up a world of
negotiating possibilities. If you focus on interests, you’re more likely to find a win-win solution than if you dig into
bargaining positions.
For schedule demands:
 Appeal to true development speed
 Appeal to increasing the chance of success
 Invoke you organization’s track record
3. Invent Options for mutual gain (win-win)
It’s your role to explain the full range of possibilities and trade-offs.
Some product options
 Move some of the desired functionality into Version 2
 Deliver the product in stages
 Cut features altogether
 Polish some features less
 Relax the detailed requirements for each feature
Some project resource options
 Add more developers early in the schedule
 Add higher-output developers
 Add more testers
 Add more administrative support
 Increase the degree of developer support
 Eliminate company red tape
 Increase the level of end-user involvement
 Increase the level of executive involvement
Some schedule options
 Set a schedule goal not an ultimate deadline until the detailed design is completed
 Agree to look for ways to reduce the development time as you refine the product
 Agree to use estimation ranges or coarse estimates and to refine them as the project progresses
Some miscellaneous options
 Provide exceptional developer support
 Provide increased developer motivation
4. Insist on using objective criteria
When you reach a deadlock, search for objective criteria you can use to break the deadlock. Don’t yield to pressure, only
to principle.
Guidelines for keeping schedule negotiations focused on principles
1. Don’t negotiate the estimate itself—you can negotiate the inputs to the estimate, but not the estimate itself.
The estimates are determined by its inputs, but only the inputs are negotiable. The results speak for
themselves
You could say something like this: “This is my best estimate. I can write a different date on a piece of paper,
but that won’t be a valid estimate. I can write a bigger number in my checkbook, too, but that doesn’t mean
that I’ll have any more money. I’ve already given the team only about a 50-percent chance of delivering the
software on time. Planning for a shorter schedule won’t shorten the amount of time it will take them to create
the product you want. It will just increase the risk of being late.”
Point out that by refusing to accept an impossible deadline you’re really looking out for your customer’s best
interests.
2. Insist that the estimate be prepared by a qualified party
3. Insist on a rational estimation procedure. It should comply with the following guidelines: (1) Nails down
features before it nails down the estimate, (2) Doesn’t provide unrealistic precision, (3) Re-estimates after
changes.
4. Weather the storm. Politely and firmly stand by your estimate. Batten down the hatches and endure the
thunderstorm of an unwelcome estimate early in the project rather than the hurricane of schedule slips and
cost overruns that will ship your ship.