Page 80 -

two weeks; another programmer will be stuck for even longer, waiting for him to com-
plete his work. Unfortunately, the project manager already committed to a deadline. As a
result, some team members will have to work overtime to make up for the lost time—
while others are left sitting idle.
When predecessors are not discovered until the project is underway, there are usually few
opportunities for correction. Critical team members are already working on other tasks,
and end dates may have already been agreed upon. What’s more, in a tight schedule, pre-
decessor problems often cascade. When one task has to wait, all of the tasks that depend
on it will also have to wait, as will the tasks that depend on those, and so forth.

Often, these cascading delays aren’t fully recognized by the team until late in the project.
Since each person performs each task in the amount of time estimated, the project man-
ager might not realize the problem throughout most of the project. To the project man-
ager, it seems that things are moving along at a steady pace; it is not until the project nears
completion that it becomes apparent that the deadline is in jeopardy.
This problem is especially hard on software testers, simply because they are responsible for
the tasks at the tail end of the software project. Since the project is in its final phase when
the problem is discovered, the testers are responsible for the bulk of the remaining work.
This is especially unfair when the root cause of the delay is in an earlier phase of the
project: the testers did not create the problem, yet they bear the brunt of the pressure!

72 CHAPTER FOUR