Page 71 -

of extra “play” built into the schedule. They have an expectation that the scope can be
changed without any impact to the schedule, because the buffers will absorb the change.

This is especially bad for the team because each person feels that she can ignore “small”
errors in her own estimates. For example, a programmer may find that she underesti-
mated her programming task because the technical solution was more difficult than she
originally anticipated. If there is a buffer, she may feel comfortable not reporting that mis-
take because she assumes that it will be absorbed. Unfortunately, if the designer and tester
both made similar estimation mistakes and also failed to report them, all three of them are
now counting on using the same buffer: there will be a large overrun. Since nobody
reported any individual overruns, the project manager will not know about the problem
until after the project has already slipped; this will limit his options much more than if he
had known about the estimation problems as soon as they were discovered.

The bottom line is that when buffers are added to the schedule, Parkinson’s Law will kick
in and the work will expand to fill the time allocated to it. Luckily, the project manager
already has a tool to help him plan for the unknown or unexpected: he can work with the
team to build a risk plan (see Chapter 2). By brainstorming risks and adding mitigation
tasks to the project schedule, he can avoid some of the risks. And for the ones that cannot
be avoided, there will already be a plan in place to deal with most of them.
Adding a risk plan to a schedule that does not already include risk mitigation tasks
requires that the schedule be updated and the project plan reinspected; however, this is
not a bad thing. Updating the schedule guarantees that the schedule does not contain any
“white lies,” and inspecting it effectively communicates the team’s true estimate of the
work to everyone who will be impacted by it. If the risk plan is thorough, the stakeholders
will not be blindsided by the potential problems, because they will see that the team antic-
ipated these possibilities and has a plan to deal with them. This will remove a lot of the
pressure usually associated with project overruns.
Track the Performance of the Project

After the schedule is completed and optimized, it is ready for review. The schedule should
be inspected by the project team, either on its own or as part of the project plan. (See

Chapter 2 for the inspection checklist, which is part of the checklist for the project plan.
See Chapter 5 for more on inspections.) It is important that the people on the project team
who will do the work all agree that it represents a realistic plan for completing the project.

A copy of the version of the schedule that has been approved should be set aside and used
as the baseline. A baseline is a fixed schedule that represents the standard that is used to
measure the performance of the project. Every time a change to the scope of the project is
approved (see Chapter 6 for information on change control), the schedule should be
adjusted and a new revision of the baseline should be used instead. Many project manage-
ment software packages have a feature that allows the project manager to maintain a
baseline schedule and track revisions to it.

PROJECT SCHEDULES 63