Schedule Contingency

[Tony Bolstad]

In almost all cases, even when I don't use this contingency task at the end of the schedule, I develop my projects so that there is some float in the longest chain. I try to have a cushion between the last task in the schedule and the contractual finish date.

A rule of thumb that I have used is to have a minimum of 5 days of Total Float for every 12 months of project duration. Thus a two year long project has at least 10 days of TF. In EPC type projects with multiple entities I try to double this figure as a week of time can be lost quite quickly. I try to be careful and not acheive this extra float by being overly optimistic in activity durations or the use of flaky logic techniques.

I have experimented a couple of times with having this buffer at the end of each major phase of a project (Eng'g, Procurement, Construction, Commissioning), and it seems to work well. I still need to formalize the rules for draw down and communication so that it is more transparent to all of the parties involved. At the moment it is more of a planner/schedulers technique than a project management practice.

[johntfrost]

I would like to revitalize this discussion and hear opinions of the application and use of Schedule Contingency (Not Total Float) in a formal EVMS environment.

Given the following scenario....

• Project Schedule has been developed and resourced loaded and scrubbed to a five year duration, with a scheduled completion date of Dec 08 (for sake of discussion).
  
• A probabilistic risk analysis is conducted using PertMaster that identifies a need for 3 months of schedule contingency.
  
• Based upon the risk assessment, the contract completion date is agreed upon of March 09.

There are two equally compelling schools of thought as to how this should be reflected in the project schedule and the Performance Baseline (PMB).

The first approach is that schedule contingency should be included in the project schedule and PMB by the addition of "Contingency" activities tied to various key interim milestones such as the completion of Preliminary Design etc. or by setting a "must finish" constraint on the completion milestone and generating a total float equal to the contingency. Either of these approaches would have the effect of generating earned value performance relative to the contract completion date, however there is no structured control over the use contingency during project execution.

The second approach would be to establish the project baseline based upon the original schedule and hold the schedule contingency offline, (not included in the PMB). Inclusion of the schedule contingency into the baseline would be controlled through change control in the same manner as cost contingency. Thus the difference between the "Schedule Completion Date" and the "Contract Completion Date" would equal the schedule contingency in the same way as the difference between the PMB and "Contract Budget Base" equals the Cost Contingency.

This is a hot topic in the DOE as performance against both schedule and contract completion dates are typically a metric that drives incentive fees and/or liquidated damages. The first approach tends to favor the contractor, while the second approach is more consistent with EVMS criteria that excludes contingency and management reserve from performance measurement.

Would appreciate any thoughts or opinions from others.

[pmkb]

I prefer the second approach as it helps keep the team members who are using the schedule as the basis for setting priorities in directing the effort focused on the right goalposts.

[Jos]

I'm in a situation where my client is asking me to add dummy activities for contingency into the schedules (one for engineering and one for construction).

However, after reviewing your comments I must say that I agree with the second approach and believe the constingency can be managed by adding the contingency to the baseline and even by adding the cushion between the last activity and the requiered completion date.

If I choose the first approach; I would be concerned about the amount of maintenance the scheduler would have to face to ensure the contingency activities are properly managed.

I would like to revitalize this discussion and hear opinions of the application and use of Schedule Contingency (Not Total Float) in a formal EVMS environment.

Given the following scenario....

• Project Schedule has been developed and resourced loaded and scrubbed to a five year duration, with a scheduled completion date of Dec 08 (for sake of discussion).
  
• A probabilistic risk analysis is conducted using PertMaster that identifies a need for 3 months of schedule contingency.
  
• Based upon the risk assessment, the contract completion date is agreed upon of March 09.

There are two equally compelling schools of thought as to how this should be reflected in the project schedule and the Performance Baseline (PMB).

The first approach is that schedule contingency should be included in the project schedule and PMB by the addition of "Contingency" activities tied to various key interim milestones such as the completion of Preliminary Design etc. or by setting a "must finish" constraint on the completion milestone and generating a total float equal to the contingency. Either of these approaches would have the effect of generating earned value performance relative to the contract completion date, however there is no structured control over the use contingency during project execution.

The second approach would be to establish the project baseline based upon the original schedule and hold the schedule contingency offline, (not included in the PMB). Inclusion of the schedule contingency into the baseline would be controlled through change control in the same manner as cost contingency. Thus the difference between the "Schedule Completion Date" and the "Contract Completion Date" would equal the schedule contingency in the same way as the difference between the PMB and "Contract Budget Base" equals the Cost Contingency.

This is a hot topic in the DOE as performance against both schedule and contract completion dates are typically a metric that drives incentive fees and/or liquidated damages. The first approach tends to favor the contractor, while the second approach is more consistent with EVMS criteria that excludes contingency and management reserve from performance measurement.

Would appreciate any thoughts or opinions from others.

[davilara]

I consider Critical Chain Theory to be flawed. It promotes the use of buffers that hide true float and might artificially delay some Early Dates. The same happens with the addition of some fat to account for bad weather, also the introduction of finish constraints further obscure the view. What happens if you set Friday as a rainy day in your calendar and it does not rain, your schedule will misled you into not assigning any work on Friday, and delay it for Monday.

Perhaps the best way to account for contractual requirements to include bad weather, to include intermediate milestone constraints that can create negative float and to include appropriate buffer in the form of “Invisible Fat” (if such thing exists) is to keep two separate schedules.

One schedule with all the Fat that will on average tell you about the long run, but no good to manage your job, a schedule that will satisfy the need of some Owners for it to project finish equal to contractual date.

Another schedule without the fat, without artificial finish constraints and targeting for early completion in the hope you will finish on time, this you shall use for managing your job. You shall use the one that provides an unobstructed view.

How much early can be a decision of economics versus success probability. Monte Carlo and Spider SPDM are methodologies that provide a mathematical approach to determine appropriate level of buffer.

[url]http://www.spiderproject.ro/pdf/success_probabilities_sdpm_brazil_pmi_cos_chicago_ 2008.pdf[/url]

Best Regards,
Rafael

[michaelmz]

"Managing projects involves balancing the objectives and constraints associated with time, resources, costs and scope. These are four key dimensions of any project, and each carries the risk of missing defined targets."