Schedule Contingency
A baseline schedule includes margin or a reserve of extra time, referred to as schedule contingency, to account for known and quantified risks and uncertainty. The contingency represents a gap in time between the finish date of the last activity (the planned date) and the finish milestone (the committed date). When schedule contingency is depicted this way, a delay in the finish date of the predecessor activity results in a reduction of the contingency activity’s duration. This reduction translates into the consumption of schedule contingency.
Schedule contingency should be calculated by performing a schedule risk analysis and comparing the schedule date with that of the simulation result at a desired level of certainty. For example, an organization may want to adopt an 80 percent chance that its program will finish on time or earlier. The amount of contingency necessary would be the difference in time between the 80th percentile date from the cumulative distribution and the date of the deterministic finish date in the schedule.
For some programs, the 80th percentile is considered a conservative promise date. Other organizations may focus on another probability, such as the 65th or 55th percentile. However, because schedule distributions tend to be right skewed (that is, the program has a greater tendency to finish late than early), the mean of the distribution tends to be larger than the 50 percent confidence level. Hence, the 55th or 65th percentiles are not as certain as the 80th percentile and may expose the program to overruns if they are adopted. Factors such as project type, contract type, and technological maturity affect each organization’s determination of its tolerance for schedule risk.
Schedule contingency or reserve is held by the program manager but can be allocated to contractors, subcontractors, partners, and others as necessary for their scope of work. When contingency needs to be allocated, a formal change process should be followed. Subjecting schedule contingency to the program’s change control process ensures that variances can be tracked and monitored and that the use of contingency is transparent and traceable.
Schedule contingency may appear as a single activity just before the finish milestone or it may be dispersed throughout the schedule as multiple activities before key milestones. For example, it might be appropriate to plan a contingency activity before the start of a key integration activity that depends on several external inputs to ensure readiness to start. It is preferable that contingency be held as one activity just before the finish milestone for several reasons. In general, apportioning contingency in advance to specific activities is not recommended because risks that will actually occur and the magnitude of their effects are not known in advance. In addition, dispersing contingency to specific key milestones may cause its consumption prematurely or superfluously.
Contingency that is dispersed throughout the schedule is less visible and may be harder to track and monitor. Dispersion may also encourage team members to work toward late dates rather than the expected early dates. By aggregating contingency, everyone on the project will be working to protect the schedule contingency as a whole, not simply their own portions. Finally, if contingency activities are dispersed within the schedule network, care must be taken that the contingency activities do not affect total float and, therefore, critical path calculations. Contingency activities should not become critical because no resources or scope are associated with them and they cannot practically delay a successor activity.38
Regardless of whether contingency is captured at the end of the schedule or just before key milestones, representing it as activities will help ensure that the schedule is not hiding potential problems. Contingency can also be quickly identified and zeroed out before schedule health measures are calculated or an SRA is conducted if it is represented as activities.39 Finally, schedule contingency should not be represented as a lag between two activities. Lags have no descriptive name in schedules and the associated contingency may become lost within the network logic.
Notice that contingency is not the same as total float. As described in Best Practice 7, total float is the amount of time by which an activity can be delayed before it affects the finish milestone. Total float is directly related to network logic and is calculated from early and late activity dates. Schedule contingency, in contrast, is determined by a schedule risk analysis. A schedule risk analysis compares the schedule date with that of the simulation result at a desired level of certainty and is calculated by quantifying uncertainties and risks that may affect the finish date.
A technique for inserting contingency activities within the network is to insert an activity as a predecessor to a “reference milestone.” The reference milestone is a copy of the original key milestone but has no successor. This method allows the reference milestone to shift in response to the depletion or accumulation of contingency without affecting total float values in the schedule.↩︎
If activities representing schedule contingency are not removed before an update to the SRA is conducted, they will adversely affect the results.↩︎