Planning

Overview

Planning embraces many critical aspects of the group. If the plan is poor, chaos reigns, the group often fights out of frustration, and success is endangered. The physical manifestation of The Plan is a document (possibly electronic) that gives:

The total time a project will take, in all aspects of creative work, formal development, testing, and etc.
A formal breakdown of ALL aspects of the project that lead to the above calculation, to tasks of no more than five hours . (The five-hour rule)
A theoretical grouping of tasks into sub-modules, and modules, usually with subtotals for the hours of all subordinate tasks.
A calendar that contains each of the five-hour tasks so that ALL tasks have a completion date on them (and possibly a start date).
A name of the responsible party that guarantees completion of the task.
A group view of the entire project such that we can look on any day and know what each member is doing.
An individual view of any group member's schedule so that we can know what the trajectory of that member's contributions look like, their total time projected, their time each week, and a complete list of all tasks for which they are responsible.
A complete dependency graph so we know what tasks depend on which other tasks.
A critical path through the project with dates, so we know which tasks cannot be moved.

Notes:

The planner ensures that the group identifies all of the tasks to be completed for the finished group project. These tasks include not only all of those in the design (that is the coding), but also all of the non-design aspects of the project as well, such as group meetings, project booklet, testing, finding alternate servers, the handling of personnel issues, and so forth.
Once all of the tasks have been identified, the planner must ensure that they are all decomposed into small tasks of five hours or less. Each of these tasks must be an easily identified cognitive entity, the scope of which each group member can grasp. The time to complete each task must be specified.
The planner must make a dependency graph of each of the task so that it is clear which work can be done in parallel, and which has to be done in series (that is, what has to be done first before a following task can be started).
One bottom-line name must be assigned to each of the tasks.
Each of the task/name/time triads must be inserted into both the master schedule, and the individuals' schedules, according to the project task dependency contraints (see above) and the group members' scheduling constraints.
Once the schedule is complete, the planner must do the grunt work of reminding group members about the deadlines, and must continually verify with them which tasks have been completed, which are on schedule, and which might be at risk of slipping. Design your planning system so that there is group acknowledgment of completed tasks, for all to see.
If the schedule slips, the planner must dynamically repeat the previous steps in creating a new schedule, and re-assigning tasks.
The planner must have (and in our case present) a clear picture of how much time the whole project will take, who will be doing what for how long and when, and the various major deadlines the group will be meeting.