Summary of Important Points

Summary of Important Points

Table 7-2 provides the highlights of this chapter.

Table 7-2: Summary of Important Points

Point of Discussion

Summary of Ideas Presented

Quantitative time management

• The major program milestones that mark business value drive the project at the highest level.

• The program milestones come from the business case.

• Program milestones do not have a probabilistic character.

• The program logic is found in the detail project schedules. Lower level schedules are in network form, preferably the precedence diagramming method, and tie together the various deliverables of the WBS.

• The difference between the network schedule and the program mile-stones represents risk.

• Every network schedule task has not only a specific beginning or ending, but each task also has an "earliest" or "latest" beginning or ending.

Critical path

• The most common outcome of the schedule network is the identification of the critical path.

• The critical path, and in fact there may be more than one through the network, may not be the most important path for purposes of business value or functionality.

• The critical path establishes the length of the network and therefore sets the overall duration of the project.

• There is no float or slack along the critical path.

• The "near-critical path" is one or more paths that are not critical at the outset of the project, but could become critical due to performance differences along paths during the course of the project.

• The amount of forward-backward path inequality in any path that is the float or slack in the path.

Central Limit Theorem and schedules

• From the Central Limit Theorem, the distribution of the output mile-stone will be Normal regardless of the distributions of the individual tasks in the network.

• Given the symmetry of the Normal curve, there is just as likely a possibility that the schedule will underrun (complete early) as overrun (complete late).

Monte Carlo simulation

• By computer simulation using a Monte Carlo simulation program, the network schedule is "run" or calculated many times, something we cannot usually do in real projects.

• Outcome: a probability density distribution, with absolute values of outcome value and a vertical dimension scaled to meet the requirement that the sum of all probabilities equals 1.

• Outcome: a cumulative probability distribution, the so-called "S" curve, again scaled from 0 to 1 to 0 to 100% on the vertical axis and the value outcomes on the horizontal axis.

Architecture weaknesses

• At every merge point of predecessor tasks, think "shift right" about the schedule.

• Parallel paths that become correlated by sharing resources stretch the schedule!

• Another problem common to schedule network architecture is the so-called long task.

Critical chain

• The tasks on the critical path require statistical distributions to estimate the range of pessimism to optimism, but the median value, the 50% confidence level, should be used.

• All task activity in the project schedule network that is not on the critical path should be made subordinate to the demands of the critical path.

• There should be "buffers" built into any path that joins the critical path. A buffer is a task of nonzero duration but has no performance requirement.

• The project manager must "gather up" the excess pessimism and put it all into a "project buffer" at the end of the network schedule to protect the critical path.