Page 65 -

There are many reasons why one task may be dependent on another. The most common
is the causal relationship: the dependent task relies on a work product generated by the
predecessor. For example, the reviewers of a document cannot review it until it is com-
pleted, so a review task is dependent on the task that generates the document that will be
reviewed. One task may also depend on another because they share the same resource: if
there is only one programmer who has the knowledge to perform two different program-
ming tasks, he cannot do them both at the same time; one must be dependent on the
other. If there is no specific reason that one of those two programming tasks must be done
before the other, then the project manager and programmer have discretion to perform
them in either order.

The easiest way to maintain the resource allocations and dependencies is to use a project
management software package. Most project management software allows the user to
maintain a list of tasks and to associate resource information and predecessor information
with each task. (It is possible to do this by hand, but very few project managers create
schedules this way. Project management software is almost always used for this purpose.)

Create the Schedule
Once the resources and dependencies are assigned, the software will arrange the tasks to
reflect the dependencies. The software also allows the project manager to enter effort and
duration information for each task; with this information, it can calculate a final date and
build the schedule.
The most common form for the schedule to take is a Gantt chart. This is a type of bar chart
developed by Henry Laurence Gantt, an American engineer who was prominent during the
first two decades of the 20 th century. Over the past century, Gantt charts have been used on
major civil engineering projects (including the Hoover Dam and the U.S. interstate highway
system), and it is now the standard way to document software project schedules.
Figure 4-2 shows an example of a Gantt chart. Each task is represented by a bar, and the
dependencies between tasks are represented by arrows. Each arrow either points to the start
or the end of the task, depending on the type of predecessor (see Figure 4-1). The black dia-
mond between tasks D and E is a milestone, or a task with no duration. Milestones are used to

show important events in the schedule. The black bar above tasks D and E is a summary task,
which shows that these tasks are two subtasks of the same parent task. Summary tasks can
contain other summary tasks as subtasks. For example, if the team used an extra Wideband
Delphi session to decompose a task in the original WBS into subtasks, the original task should
be shown as a summary task with the results of the second estimation session as its subtasks.

The Gantt chart in Figure 4-2 demonstrates the following predecessor types:
• Task A is a Finish-to-Start (FS) predecessor of Task B. Task B does not start until Task A
is complete. For example, code cannot be reviewed until it is written, so the program-
ming task would be a Finish-to-Start predecessor to the code review task.

PROJECT SCHEDULES 57