Schedule Contingency

[Rob Green]

Following on from reading the excellent articles both Harry & the PMKB highlighted on Critical Paths, I would like to hear from the community about the use of schedule contingency in a project's critical path.
During a review on a project's schedule (prior to project commencement) I was asked what amount of contingency had been built into the critical path. That is, how much fat had been factored into Critical Path. The schedule contained over 30 contract milestones of which certain key milestones were on the critical path. Resource levelling along with the Early / Late dates were analysed and the project schedule was considered achievable prior to the review.
Is this a common practice across business / industry to built fat into the Critical Path?
Is it a matter of increasing the durations (by e.g. 10%) of activities on the critical path or introducing dummy activities on the critical path?

[pmkb]

[url=http://en.wikipedia.org/wiki/Parkinson%27s_law]Parkinson's Law[/url]: "work expands so as to fill the time available for its completion."

I would not recommend building in fat/contingency into the critical path schedule if the schedule is used to drive the execution of the project. It is still possible for management to commit to a project end date later than the critical path schedule allows, but the critical path should be as tight as possible while still being workable/reasonable, IMO, to offer the best opportunity for an optimal conclusion.

[jjf_1975]

Hi Rob

I was asked the same thing during Offer Definition - and was equally bambozelled by DMO's request....for years they have been acquising contractors of having too much fat in the schedule...now they are asking us 'where is it?'

Under the Defence Supplement to AS 4817-2003 they recommend "Rework" elements (finally they realise that is is reality that rework is likely to occur)...IMHO...that is 'schedule contingency' because you may or may not use that time. I also think that activities specially for "risk mitation" would be considered a schedule contingency ie the effort required to mitigate a risk.

I also ensure that Contractual Dates are set to "On Target" to baseline, then move to "No Later Than" to progress. Which brings an interesting conundrum...because the Milestone will show as 0d float because of the contraint, but the activities leading up to it might have say 10d flow because you have constrained it. I identify where this is the case and highlight that as schedule contingency...however...you need to make sure that the succeeding activities are linked to the milestone and not to the task for it to be consider schedule contingency.

Anyway...happy to discuss further, I'd like to really work out what DMO are up to as well.

Regards
Joanne

[Bernard]

Is this a common practice across business / industry to built fat into the Critical Path?

Not in my experience.

[harrywaldron]

... As Bernard shares, we should avoid padding the schedule as much as possible. You want your schedule to be as realistic as possible.

The PMM we built at work, encouraged project teams to break down complex tasks in the WBS process as granularly as possible, e.g., inside every large task are several little tasks trying to escape

Thus, a well throught out project plan should have perhaps some cushion for unknown conditions, e.g., working with 3rd parties on critical tasks where you don't have direct control.

I think in creating project plans, PMs are likely to try to pad some nebulus or complex tasks, where there are a lot of unknown variables. Many of us have created plans like this, as sometimes it's better to the hero and come in early on a highly complex task, than to schedule things too tightly.

Of course, this depends on whether PMs have the luxury of setting the date based on true CPM calculations or whether the project is "goal driven" and to be delivered on a given end date. When a project has to be done by January 1, 2006, there most likely won't be a lot of padding involved.

[SOACJ]

Would depend on who owns the float wouldn't it?

[pmkb]

I think it's more a case of what you are hoping to achieve with the schedule (ie. what is its purpose).

[Rob Green]

At the time off this particular example, the aim of the continguency was to cover the risk of slippage of a major sub-contractor deliverables. This sub-contractor, was on the project's critical path and their deliverables were software related.

[Tony Bolstad]

Hello,

I'm new to the forum and I see that this is pretty old but I'd like to add my comments to this topic.

I have had success in treating schedule contingency similar to how we treat estimate or job cost forecast contingency. This is similar in concept to the Critcal Chain theory and designating the project buffers which is another way of turning Total Float into a task.

If we make each activity duration as accurate as possible and weed out the padding and hidden contingency that is added consciously and subconciously, then add an activity at the end of the schedule equal to the Total Float to make the total project contingency visible, we can then establish rules for drawing it down the same way we do cost.

In this way we do not automatically and/or incrementally consume Total Float during an update cycle in order to maintain the project end date, but are forced to consider a reduction of the contingency task at the end of the project and account for it just like we do for cost items. This would also allow for use of a contingency draw down schedule that would more accurately reflect potential savings (time!) at the end of the project. Conversely, as the project risk register is updated there may be a need to forecast more contingency time at the end of the project as information and options are developed but are not yet ready to be put into the schedule.

Too often we gradually consume all of the Total Float during the first 50% of a project then spend the next 50% managing the cumulative impacts in order to maintain the project end date. Maybe if the first impact, which seemed minor at the time, pushed the project end date and forced the project team to decide whether to spend valuable contingency on that activity we might see a more proactive approach to recovering from impacts earlier in the project cycle.

This practice can help reinforce the time=money principal.

[pmkb]

Interesting approach Tony. Does this mean that your schedules do not typically have a 'classic' critical path (where total float = 0)? Or are the contingency tasks only added for sub-critical paths?