Software engineers determining the next schedule.
... the product is understood and the project size has been estimated.
✥ ✥ ✥
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" [BibRef-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 ComparableWork, "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." [BibRef-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.
Therefore:
Reward developers for negotiating a schedule they prove to meet, with financial bonuses (or at-risk compensation; see CompensateSuccess), 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 (RecommitmentMeeting).
✥ ✥ ✥
Help delineate the schedule with NamedStableBases. Grow as needed with PhasingItIn. Define initial targets with WorkQueue. Make sure SomeoneAlwaysMakesProgress.
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.
DeMarco talks about rewarding people for accuracy of schedules; see [BibRef-DeMarcoBoehm1986]. Verify this reference... Also, read about the place of promptness in [BibRef-ZuckermanAndHatala1992].
You don't need a full schedule--perhaps no schedule at all--to get started. See GetOnWithIt and BuildPrototypes.