Comments

  I'll provide a general sketch of the best and worst characteristics of schedule plan documents from past terms.

Best

Some careful estimate of times, perhaps using something from the book. Very thorough layout of each team member's available times. Selection of milestones so that integration, testing, communication and review, and documentation goes hand in hand with development, thereby keeping the development honest and well-tracked. There is a meeting schedule planned, including an indication of the agenda to be used. Task chart rich, detailed (but not excessively detailed), and with cross dependencies among separate members so that there is careful checkpointing. Prioritization of tasks so that lesser ones can be sacrificed. Diffuse development, which avoids ``killer'' nodes that bottleneck the development and ruin things if they fail. Careful assessment of risks. Thorough charts and timelines, explicitly stating dates. Managerial establishment of means of communication and a designated central directory on the Unix machines to facilitate up-to-the-minute sharing. Responsibilities assigned according to individual strengths and availabilities.

Worst

Design consists of a small number of very large tasks or a huge number of picky little tasks. Everybody gets an equal number of tasks and no justification is given for the assignments. An unreasonably large number of hours is assigned to each person, and task-time estimation is poorly thought out. Everybody goes off and does their own thing independently without any clear lines of oversight or management responsibility. No files are communally available. There is a sort of a meeting every week in which each team member is supposed to ``report progress'', but (since everybody is acting independently and no testing and verification is done until the end) progress can't be reliably assessed. Everything is expected to come magically together in one great big wonderful ``integration'' step a couple of days before the due date.