Page 68 -

programming). Project schedules are usually broken down into distinct phases which corre-
spond to the major software engineering activities: scope, requirements, design, develop-
ment, and testing. Each of these phases is usually represented on the Gantt chart as a
summary task, with a milestone as the final subtask to mark the end of the phase.
Once again, the project manager should make sure that the representatives from the engi-
neering team and stakeholders attend all of those meetings. The difference between a
milestone review and a progress one is that the project manager writes up a report after
the milestone review. This report should list any schedule delays or changes, any modifi-
cations to the scope, and any serious issues that came up since the last milestone review
meeting. These reports should be stored with the project plan.

The schedule should always be updated by the project manager. However, the information
that is used to update the project schedule should be agreed upon at status meetings. After
every status meeting, the schedule should be updated with any changes that were agreed
upon in the meeting. If a team member discovers that a problem has occurred between status
meetings that could cause a delay, the project manager should be notified immediately. If the
project manager feels that the problem is serious enough that it cannot wait until the next
scheduled status meeting, an impromptu meeting should be called, and the team should talk
about the impact to individual tasks so that the schedule can be kept up to date.
A final milestone should be added to the schedule for a postmortem meeting run by the
QA lead (see Chapter 8).

Optimize the Schedule
Many times, the project manager has options in how the schedule is arranged. There is
often flexibility in the order in which the tasks may be performed, or to whom they may
be assigned. Most schedules end up with several sequences of interrelated tasks: a require-
ments document may have a string of elicitation, documentation, and verification tasks;
software must be designed, coded, and reviewed; test plans must be written, reviewed,
executed, repaired, and regressed.

In many schedules, there is some slack in these sequences. In a sequence of tasks, slack is
the amount of time that any of the tasks can be delayed without causing the due date of

the final task in the sequence to be delayed as well. A tight schedule has very little slack; a
delay in any task will cause a delay in the due date. For example, a task may depend on a
work product, but the person who will perform that task may not be available until three
days after the work product is scheduled to be complete; this creates a three-day gap in the
schedule. It may be possible to rearrange the tasks in order to reduce that slack—for
example, the task that is occupying the resource could be moved to a point later or earlier
in the project, or assigned to another resource. These decisions can make an enormous dif-
ference in the final due date.

It is important to keep in mind that, while there may appear to be slack in the schedule, it
may simply be that all of the resources in the project are allocated to another task; there
just happens to be some time between a task and its predecessor. Many project manage-
ment software packages have a feature that summarizes the allocation of each resource
60 CHAPTER FOUR