Context:
Forces:
If you make the schedule too generous, developers become complacent, and you miss market windows.
If the schedule is too ambitious, developers become burned out, and you miss market windows.
If the schedule is too ambitious, product quality suffers, and compromised architectural principles establish a poor foundation for future maintenance.
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 meeting the schedule, 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 well-known 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.
Design Rationale:
MIT project management simulation; QPW. 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.
Next: Form Follows Function