Page 69 -

per day in the schedule, which can be used to check for slack periods in which resources
are unallocated. This is also helpful for ensuring that no resource is over-allocated, or more
than 100% allocated to multiple tasks simultaneously. If any resource is over-allocated, it
means that there is a dependency between two tasks that was not discovered. When this
happens, the schedule is guaranteed to be inaccurate.

Some project managers fall into the trap of using slack in the schedule as a way to mitigate
risk. They think that if there is extra space between two tasks, then the second task will
have some protection, in case the first task is late. This is usually a mistake. Most project
managers who try to do this find that Parkinson’s Law kicks in—the work in the first task
expands to fill up the slack. Instead of using slack to mitigate risk, the definition of the task
should be expanded to include an activity that may mitigate the risk (see Chapter 2 about
risk mitigation). This new task will take longer, and the schedule should be updated to
reflect that. That said, if there is unavoidable slack in the schedule, it means that the
schedule can tolerate some delay without affecting the due date of the project. But it is
very important not to rely on this; instead, it’s often better to plan other activities (such as
training) for the resources with slack time.
One important tool for optimizing the schedule is the critical path. The critical path is the
sequence of tasks that represents the minimum time required to complete the project. It is
the sequence that, if delayed, will delay the schedule. The last task on the critical path is
always the last task in the schedule—when the critical path is completed, the project is
done. Every project schedule has at least one critical path: most have exactly one, but
some may have two or more critical paths that complete simultaneously at the end of the
project. There is never slack in the critical path. When the schedule is most optimal, the
critical path starts near the beginning of the project and the total effort expended on each
day of the project is relatively steady.

It is very important to monitor the critical path closely. If a task that is on the critical path is
late, the project will be delayed. On the other hand, some tasks that are not on the critical
path can suffer delays without jeopardizing the expected due date for the project. Some
project management software packages highlight the critical path on the Gantt chart—this is
an especially useful feature that allows the project manager to optimize the chart visually.

Figure 4-3 shows an example of how a critical path would be displayed in a project sched-
ule. The darker tasks represent the critical path; the lighter tasks are off of the critical path.
(This figure was created with Microsoft Project 2003.)

In this example, the test preparation tasks are not on the critical path. This means that if
there is a delay in building or reviewing the test plans, then the project due date will not
change unless that delay is long enough to put those tasks back on the critical path. In
this case, that would require nine weeks. (This schedule shows the amount of play in
the schedule by depicting slack in the schedule as thin bars to the right of each task. The
“1.5wks” label next to the “Execute Test Plan B” task shows that task would have to be
delayed by 1.5 weeks to impact the due date.)

PROJECT SCHEDULES 61