Size The Schedule

If the schedule is too long, developers become complacent; but if it is too short, they become overtaxed. Therefore: reward meeting the schedule, and keep two sets of books.

## Relationships

### To be applied before

* Community Of Trust is needed in order to Size The Schedule.

### To be applied after

* delineate schedule with Named Stable Bases.
* on failure of Size The Schedule, call a Recommitment Meeting.
* make sure that Someone Always Makes Progress.
* define initial targets with Work Queue.

### Alternatives

* Build Prototypes and Get On With It are alternatives for Size The Schedule.

*Contents of following sections belong to the original Organizational Patterns website[1] and have been divided into following parts: Context, Problem, Solution, Discussion.*

## Context

... the product is understood and the project size has been estimated.

## Problem

**Both overly ambitious schedules and overly generous schedules have their pains, either for the developers or the customers.**

If you make the schedule too generous, developers become complacent, and you miss market windows. But if the schedule is too ambitious, developers become burned out, and you miss market windows. And if the schedule is too ambitious, product quality suffers, and compromised architectural principles establish a poor foundation for future maintenance.

Common wisdom says that you can trade off staff, schedule, and functionality. While principles such as Brooks’ “adding people to a late project makes it later” [Brooks1995] cast doubt on the place of staff in this equation, it’s clear that schedule and functionality trade off against each other. Ward Cunningham says in his pattern Comparable Work, “Every project must commit to delivery on a few hard and fast dates. This is actually fortunate because it is about the only way to get out of work that is going poorly.” [Cunningham1996] In a reasonable business climate, it is much smarter to hold the schedule constant and to negotiate functionality than it is to extend the schedule. The customer believes you can cut functionality, but a promise of having the yet unattained functionality at some future date leaves the customer much less comfortable. And projects without schedule motivation tend to go on forever, or spend too much time polishing details that are either irrelevant or don’t serve customer needs.

## Solution

**Reward developers for negotiating a schedule they prove to meet, with financial bonuses (or at-risk compensation; see Compensate Success), or with extra time off. Keep two sets of schedules: one for the market, and one for the developers.**

The external schedule is negotiated with the customer; the internal schedule, with development staff. The internal schedule should be shorter than the external schedule by two or three weeks for a moderate project (this figure comes from a senior staff member at a wellknown software consulting firm). If the two schedules can’t be reconciled, customer needs or the organization’s resources—or the schedule
itself—must be re-negotiated (Recommitment Meeting).

## Discussion

Help delineate the schedule with Named Stable Bases. Grow as needed with Phasing It In. Define initial targets with Work Queue. Make sure Someone Always Makes Progress. The forces come from the MIT project management simulation and from studies as projects such as Borland Quattro Pro for Windows. Another manager suggested that the skew between the internal and external schedules be closer to two months than two weeks because, if you slip, it usually reflects a major oversight that costs two or three months.

You don’t need a full schedule—perhaps no schedule at all—to get started. See Get On With It and Build Prototypes.

## References

1. ↑ http://www.svilendobrev.com/rabota/orgpat/OrgPatterns-patlets.html