## Building in Contingency

The uncertainty of an activity duration estimate must also be considered in the scheduling process. After all, a schedule is only a plan or model of what is to transpire during project execution, and the quality of the model is only as good as the available information and the experience of the people who prepare the plan. Time estimates are by no means perfect; tasks are not always well defined or fully understood and things can go wrong during execution, thus creating a degree of uncertainty in every project. The extent of the uncertainty is a function of the nature of the tasks The more developmental the project—the greater the uncertainty and the greater the degree of uncertainty—the less likely "on time" completion becomes. As a result, a contingency that compensates for project uncertainty is needed to improve the chances of "on time" completion.

An important lesson regarding the potential for "on time" completion and the need for a schedule contingency can be learned from PERT. Probabilistic PERT theory concludes that project expected comple- '4 tion time is the sum of a series of independent ran-dom variables—the expected completion times for all Critical Path tasks—and the sum of these times is -8 normally distributed. Each expected or mean task du- % ration is computed from three estimates—an opti- If mistic time, a pessimistic time, and a most likely time 5f The expected and required project completion dates are compared (see Figure 2) and the probability of on ^ time" completion is assessed. Specific probability >„ judgments are not important to this discussion but the fact that the chance of "on time" completion im-proves as the favorable difference between expected and required completion dates increases (Figure 2c) is if significant. If project completion is expected after the ^ required date (Figure 2a), the probability of "on time completion, defined by the shaded area under the normal probability distribution curve, will be low. the later completion is expected, the lower the chance of

Project start date

Required completion date

Projected lateness Negative slack ""

Expected completion tu/T

ET, ET2 ET3 ET4 ET5 ET6 ET7

ingency ve slack

Expected completion _^

ingency ve slack

Figure 2(a)-(e): Critical path probability of success distribution.

Expected completion success. When project completion is expected earlier than the specified date, a higher chance of success results. When the expected and required completion dates are the same (Figure 2b), the probability of "on time" or earlier completion, to the surprise of many people, will only be fifty percent.

The fallacy of forcing a schedule to fit a defined completion requirement is further emphasized by the probabilistic PERT relationships. Even if the fitting process were absolutely perfect—each precedence relationship properly defined, the assigned task durations equal to the functional managers' desires and the expected completion date matching the required completion date—the probability of "on time," or earlier, completion would only be fifty percent. In fact this probability assessment is apt to be optimistic, as the most likely time estimate, used to make most schedules, is usually lower than the expected time Which reflects performance uncertainty. This results from the probability distribution curve's inherent skewness (the pessimistic estimate delay being more severe than the optimistic estimate savings). Since 'he length of the Critical Path is likely to be longer than estimated, it must be concluded that a "perfectly fitted" schedule's chance of success will be less than fifty percent, and this probability will diminish further as the degree of project uncertainty increases.

A limited chance of success will also be true of a schedule that is properly developed by compressing 'he Critical Path to the point at which the expected a"d required completion dates match. To improve the diances of "on time" completion, schedule compres sion should not stop when the specified target has been met, but should be applied further to provide positive slack (schedule contingency) along the Critical Path. As seen in Figure 2, the greater the slack or contingency, the greater the chance of completing the project on time. The degree of contingency will vary with the nature of the project. As a project's uncertainty increases, more contingency becomes necessary to ensure meeting a specified end date. The experienced project manager will consider every opportunity for increasing the contingency to improve the chance for meeting, and possibly beating, the required completion date.

Obtaining the compression needed to either better, or at least meet, the required completion date is not always possible. When this occurs, the project manager must advise the client, project sponsor, and/or management of the unattainability of their completion requirement. The network schedule defining the initial expected completion date and the minimum compression needed to meet the required date, and the improvements resulting from the steps taken to meet the specified target, should serve as justification for schedule relief, increased funding, or additional resources.

If the client or management reject the evidence developed through this systematic approach and "want the date met anyway," the project manager can still benefit from the planning effort. The project manager can accept the requirement as a challenge, offering a "best shot." If the end date is met, it will result from the project manager's efforts and if the effec-

tiveJy compressed plan proves to be correct and the end date is missed, the project manager cannot be rightfully faulted for failing to support a mandated requirement. Of course, it is best to have an agreement on the schedule, as successful project completion, and not placement of blame, is the common goal.

### Managing the Contingency

Once a contingency has been established, the project manager must ensure that the available time is not misused by the functional staff executing the work, or that the client or management does not take advantage of the potential time savings to "improve" the required completion date. Contingency should be viewed as an element of the project's duration, representing time that will ultimately be spent during the period of performance, but neither the specific tasks requiring the extra time nor the cause are known to the project manager when the contingency is established. The project manager should support contingency use only when needed to solve a particular problem, as unused contingency will result in early project completion. Therefore, contingency should be treated as a reserve, controlled by the project manager, for use by the functional staff when needed to deal with specific execution issues.

Do not hide a contingency in the schedule by spreading the spare time among the project tasks and do not permit estimate "padding." If a task duration is overstated to include a contingency, the extra time will most likely be lost during execution, as Parkinson's law will prevail. The work will expand to fit the available time and the buried contingency will ultimately erode.

Identify any extra time as a contingency and keep it separated from the specified tasks, incorporated as a distinct block of time at the end of the schedule. If the project manager is concerned about the risk of highlighting the extra time (e.g., relaxation by the functional staff executing the work, or a client or management move to shorten the schedule at the expense of the contingency), then the contingency should be disguised. This can be achieved by either creating a fictitious task at the end of the project containing the total contingency or by inflating the duration of the final project task or tasks, the immediate predecessors of completion. In either case, the functional staff, client, project sponsor or management will not easily abuse the contingency and any slippage experienced during the project will eat into the time allocated to these final tasks. If an adequate contingency has been established, this erosion will merely reduce the available time for these tasks to their original duration estimates. Disguising the contingency is not encouraged, as an open and honest working relationship between functional and project personnel is important to a successful project; and the client, sponsor, and management must be aware of true project status, if their complete support is expected. However, disguising the contingecy is an approach available to the project manager who has previously experienced schedule abuse and ultimate contingency erosion.

### Summary

Completing a project "on time" (meeting a specified end date) is not a responsibility to be taken lightly. "Wishing" will not make it so, nor will preparing an unsubstantiated plan that gives the appearance of feasibility. One cannot force fit a schedule into a predefined time constraint and then casually assume that the work will be done on time. If the plan is not based on sound information and logical work flow patterns, as delineated by the functional entities responsible for executing the work, then the plan will offer little chance for success. The key to successful schedule performance lies in first developing a realistic schedule, acceptable to the functional organization, and then using this schedule as the basis for controlling the work as it is performed.

Reference

1. Brooks, Fredrick P. |r. 1975. The Mythical Man Month.