1.8
Updates:
- none
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.