Use of Delay Allowances, Buffers etc

Everyone knows that under resource constraining the critical path changes in unsuspecting ways, therefore the near critical paths.

Everyone knows the unsuspecting happens, that unexpected delays and even the consumption of float by others will change near critical paths and in occasions critical paths.

Buffers are positioned to protect original critical path and original near critical paths. But critical path and near critical path changes as the job progress. The only buffer that might maintain its validity will be a single buffer at the end of the job (milestones) if you can adjust its value . This is equivalent to targeting for early finish in the hope of finishing on time with an automatic and valid adjustment in buffer value. I guess we all understand buffers are not static either.

I don't want to be targeting for the protection of float in the wrong paths. Do you?

Stop using intermediate buffers as if garlands to a Christmas tree, wrong garlands might get your tree on fire.

Stop fooling people and yourself, it might backfire.

Do not underestimate people at the jobsite, they know their job better.

• They understand better the concept of targeting for early date in the hope of finishing on time than theory of buffers. 
• They will observe it to happen as the project goes on and actual progress slips with relation to early target.
• They understand the difference between the early target and your contractual finish date is the true buffer. A buffer that will be correctly reduced or increased (very rarely but might) as you update your schedule.

I believe either Mike Testro or Gary or both in other postings have suggested to target for early finish, to set a fixed milestone and with a Hammock between projected finish and contractual finish milestone you will get your final buffer adjusted. To me this makes sense if you do not want to get into probabilistic modeling and the added benefits of its use because your software does not help much with probabilistic modeling.

I still find it to be a supperior approach to management to use an optimistic scedule to manage actual operations and the use of a most probable schedule to project into what is the most probable future. Life is not a deterministic event, at least not before you die.

"Finally, any client delays which affect the optimistic but not most likely completion date may go uncompensated."

I guess which is to be used for delay analysis depends on the contractual "ownership" of float. Unfortunately there is too much emphasis on using CPM as a claim tool rather than a management tool, more frequent than not these two are in conflict.

Regards,

Rafael

Just a note of caution regarding maintaining both an optimistic working schedule and an most probable reporting schedule:

Without the functionality Spider gives you to update both simultaneously, this approach doubles the planning workload and introduces a lot of oportunities for double-handling errors.

Also, if your projects require client deliverables at key points, you have the possibility of client and project team planning on different dates for when these deliverables are required

Finally, any client delays which affect the optimistic but not most likely completion date may go uncompensated.

Cheers,

G

Andrew,

Be careful with the use of late dates for procurement, late dates are computed using a backward pass computation so late date will make successors become critical. Using available free float is another thing.

I also believe, though not sure, ALAP "As Las Late As Possible" does not work equal on different software, maybe some implement the ALAP to consume all float while others implement it as to consume only available free float.

Perhaps providing functionality to implement both might be useful.

Regards,

Rafael

I believe buffers shall not be modeled on the schedule you use for actual management, you shall use an optimistic schedule for management.

1. The optimistic schedule will have no buffers.
2. Buffers shall be applied to a target schedule simply by modeling the most probable delay events. Some events will be better modeled by increases in activity durations while others such as impact of rain will be better modeled by reducing available time in your calendars. By the same token resource availability changes with time or seson shall also be considered.
3. Applying buffers as an activity can yield wrong models. We avoid this approach.
4. As the job is updated both the optimistic schedule and the most probable schedule shall be updated keeping the models valid.

We usually present to the Owner the most probable schedule in accordance to his requirement not to explicitly show buffer activities and use the optimistic schedule for actual management of our jobs. We target to early (optimistic) dates in the hope will attain target (most probable) dates.

 I believe the basic procedure of implementing buffer modeling can be done within any software, the application of mathematically correct statistical functionality is another thing.

Because we use Spider Project by adding a third model, a pessimistic model, we can get very useful statistical metrics without the need for Monte Carlo. By merely updating one of the models the other two are automatically updated at the click of the mouse. It is well known by older schedulers that the initial PERT model was wrong, the methodology by Spider might seem similar but it is not. Original PERT methodology used a single model with a single critical path. Spider approach can accommodate for different critical paths as it uses 3 models.

Use critical chain method...

Hi Andrew

Vladimir is right - it is good planning practice to allow a time risk buffer at the end of a programme to allow for Contractor's potential problems.

Point your PMO towards the NEC group of contracts where this is a contractual requirement.

Also the Society of Construction Law Protocol 2002 where use of a time risk buffer is said to be "prudent planning practice".

PowerProject is the only software that I know of where a task can be converted into a buffer task and your PMO is right to some extent in that a PowerProject buffer will always show critical even if it is not on the critical path.

Insofar as the last task on a programme is always critical this is not usually a problem.

I agree with not using ALAP constraints since it does distort the available free float and gives a misleading concept of potential start dates.

I only use ALAP for lead in procurement or design tasks 

Best regards

Mike Testro

You shall create a buffer at the project end and buffers preceding major milestones.