Page 214 -

CHAPTER 7 PROJECT SCHEDULING AND TRACKING 185

7.7.2 Tracking the Schedule
The project schedule provides a road map for a software project manager. If it has
been properly developed, the project schedule defines the tasks and milestones that
must be tracked and controlled as the project proceeds. Tracking can be accomplished
in a number of different ways:
• Conducting periodic project status meetings in which each team member
reports progress and problems.
“The basic rule of
software status • Evaluating the results of all reviews conducted throughout the software engi-
reporting can be neering process.
summarized in a • Determining whether formal project milestones (the diamonds shown in Fig-
single phrase: ‘No
surprises!’.” ure 7.4) have been accomplished by the scheduled date.
Capers Jones • Comparing actual start-date to planned start-date for each project task listed
in the resource table (Figure 7.5).
• Meeting informally with practitioners to obtain their subjective assessment of
progress to date and problems on the horizon.
• Using earned value analysis (Section 7.8) to assess progress quantitatively.
In reality, all of these tracking techniques are used by experienced project managers.
Control is employed by a software project manager to administer project
resources, cope with problems, and direct project staff. If things are going well
(i.e., the project is on schedule and within budget, reviews indicate that real progress
is being made and milestones are being reached), control is light. But when prob-
The best indicator of
progress is the lems occur, the project manager must exercise control to reconcile them as quickly
completion and as possible. After a problem has been diagnosed, 10 additional resources may be
successful review of a focused on the problem area: staff may be redeployed or the project schedule can
defined software work
product. be redefined.
When faced with severe deadline pressure, experienced project managers some-
times use a project scheduling and control technique called time-boxing [ZAH95]. The
time-boxing strategy recognizes that the complete product may not be deliverable
by the predefined deadline. Therefore, an incremental software paradigm (Chapter 2)
is chosen and a schedule is derived for each incremental delivery.
The tasks associated with each increment are then time-boxed. This means that
the schedule for each task is adjusted by working backward from the delivery date
for the increment. A “box” is put around each task. When a task hits the boundary of
its time box (plus or minus 10 percent), work stops and the next task begins.
The initial reaction to the time-boxing approach is often negative: “If the work isn’t
finished, how can we proceed?” The answer lies in the way work is accomplished.
By the time the time-box boundary is encountered, it is likely that 90 percent of the

10 It is important to note that schedule slippage is a symptom of some underlying problem. The role
of the project manager is to diagnose the underlying problem and act to correct it.