Urgent, Continuous Programme Refusal......

Schedule Risk Analysis [SRA] will not automatically get your schedule to adequate buffer level.  You use SRA to see what are the probabilities of success under current updated schedule and if they are not good enough then you adjust your plan to get back into good probabilities of success.  You do not use SRA for curiosity you use SRA for Buffer Management, it is basic SRA theory.  Some say SRA is as subjective as the choice of probability distributions. But to use SRA rather than mere guesses to determine what is a good enough buffer for current schedule is a better approach.

To my knowledge most schedulers look for Buffer(s) by modeling buffer as an activity, preferably a hammock.

Instead of using this simple approach others use a more granular approach and calculate buffer for every activity as the difference between the Critical Schedule and current update instead of the more common approach as described before.

When using SRA, I prefer to look at trends on the probability of success. When not using SRA I track Buffer(s) by modeling buffer as a hammock.

http://www.planningplanet.com/sites/default/files/guild_articles/1/meth…

Hi Julie,

Firstly please in the future start a new thread rather than resurecting a very olf one like this.

wrt your question: Yes it is reasonable to expect the buffer TRA duration to be reduced over time as risks are mitigated, impacted or retired.

However different organisations have different ways of handling this reduction:

1) Some will re-asses the risk based on an updated register and/or monte carlo simulation run every month and adjust accordingly. This I think is what you are expecting.

2) Others will apply a basic formulae like if the project is 50% complete, the buffer duration should 50% of original.

3) Others will assign specfic milestones in the programme which when met will trigger a reduction in the buffer duration. This seems to be what your contractor is doing.

In my opinion though I prefer Option 1, all of the above are viable approaches and your contractor going with option 3 is not sufficient reason to reject the programme.

If you are concerned that their approach to TRA is not generating a sufficiently robust Planned Completion date, you could ask them to provide in the schedule narrative a more detailed explanation/justification of their approach, or if the relationship is good enough, just have some unofficial chats about it -share your concerns but be willing to be convinced.

Cheers,

G

For better visibility on what is Available Terminal Float versus Total Available Float [Shared + Available Terminal Float] and any Buffer I suggest using hammock activities to represent any buffer/reserve [including Terminal Float].

• If a Contractor by his actions delays project completion he reduces his buffer, his Available Terminal Float.
• If Client by his action delays project completion an Extension of Time [EOT] shall be applied to Contract Finish Date.

In the following example I used a formula to calculate Shared Float as a user defined field.

  
Hi Julia,

I'm no expert on NEC3 but I would say this is fair. As an Employer it is your right to reject a programme under clause 31.3 if you feel that it "does not represent the Contractor's plans realistically", so there should not be a problem with them justifying this 20 day period to you.

However, in my experience (granted this is only 5 years, so a small period compared to some) it is the tendency of many to underestimate the "unknown unknowns" and as a result end dates move much more often to the right than they do to the left. It is more likely that the 20 day period was an underestimation of the potential risk impacts to begin with, then it is an overestimation now.

I would guess that the planned completion is currently closer to what will actually happen, then if you reduce this activity. Of course I am not familiar with your project, its planned duration of remaining works, or the risks associated with it, but I personally would rather see them err on the side of caution than overcommit.

It would be a different story if we were talking about terminal float but ultimately if things do slip and Completion ends up being on that post TRA date, it will be on your Contractor to pay delay damages and so it is in their best interests to try to recover lost time and mitigate against future risks. It is not as though by accepting a revised programme showing the planned Completion beyond the Completion Date you are accepting contractual date slippage so I wouldn't worry about it. But that's just me.

Guys

I'm currently working on the employers side and reviewing contractors programmes under NEC. I am having issues with TRA in that the programme has both TRA shown at activity level (ie there is a TRA col showing the amount of TRA included within the duration of an existing activity) and also a TRA activity at the end of the programme (20 days duration) linked from the last task completion and the planned completion date. The planned completion date is now later than the contractual completion date due in part to a contested Compensation Event .

Whilst I am happy with the TRA being shown at activity level as this is "dealt with" during normal programme updates. My issue is with the activity at the end of the programme. I have no visibility as to how and when this will be expended by the contractor. Under NEC 3 can I ask for this information? The contractor has experienced delays (c. 2 weeks) due to impacted risks (their risk) but have not reduced this activity at all. Is this unreasonable or is it considered to be their "buffer"?

I have held meetings to discuss this issue and their stance is that they won't give any of it up until the building is water tight and that other risks may materialise. However, I know (unofficially) that some of the risks were attributed to the ground works which has now finished therefore some of the risks should be retired & the TRA reduced.

Any help /advice on this matter would be greatly appreciated

Regards

Julie

Geoff,

As previously stated, the best thing to do is to discuss with the client the reasons for rejection. Sit down at a table, face to face, with a copy of the contract and a copy of the programme, and agree what needs to be changed to get approval.

For example, I have seen a number of methods of representing TRA be accepted. This could be as basic as adding a custom column showing the amount of TRA included within durations of particular tasks or wbs levels, or as complex as having a seperate TRA activity linked FS(0) to each activity within the scheduled deemed to be at high risk of delay.

The NEC form of contract relies heavily on good coommunication and a collaborative attitude between all parties to work properly. Lead the way in modelling this behaviour.

 true shrinking buffers - I like it.

While statistical methods are good at helping you to determine the impact of your buffers on the probabilities of success the use of such functionality makes it transparent what are your buffers are and the status of them.

While I have my software preference there is no doubt Asta PP got to be watched.

It is a pity American practice requires you to use all available contract time in your baseline by virtue of common law, unless specifically allowed in the contract, which never happens. Becuase use of buffers is considered a mockery of this requirement, we cannot make use of this functionality. The British practice is correct and hope eventually our institutions will get it.

Best regards,

Rafael

Hi Geoff

Time risk allowances are best set as Buffer Tasks between the last task completion and the contract completion date.

There are usually 2:

1.  Contractors time risk buffer which is only used up if the Contractor delays the works

2.  Employers time risk buffer which covers the Employers Dealys.

They are usually links FS from the last task to gthe completion date.

ASTA powerproject is the only software that will create true shrinking buffers - I would suggest that you use solid bars and reduce them manually as and when required.

Best regards

Mike Testro

A/Es are just as likely as Contractors to display "incompetence, negligence, or malice" in their review and response to submittals.

Malice on the hands of a knowledgeable reviewer can cause a lot of damage, more damage than incompetence on part of the reviewer.

Sometimes the only way out is to establish a claim. If the A/Es are abusing the process then ignoring the real issue will not solve the issue, you got to confront bullies, the sooner the better. If the A/Es are proved correct then you have an internal problem. In any case the claim procedure shall result in a change of attitudes for the good of the job.

A claim on time is better than a claim too late, after all damage is done, no matter who is to blame.

Note that for the sake of the debate I am taking sides with you, there is not much information to make a responsible recommendation. If you expose their specific reasons for their refusal it might help us to make a better contribution.

The Clauses you refer to relate to NEC Contract Programme requirements.

In summary they relate to:

31.2        Detail in the Programme

31.3        Acceptance of Programme

32.1        Revised Programmes

You really need to review the programme requirements stipulated in the Contract and arrange a meeting with the Employer to discuss and resolve the outstanding issues. It is not unusual to have to have several iterations of the programme before it is accepted, but make sure you keep a log of submission and response dates, also record the amendments you make.

Hai,

I wish to help you ,if i know the referred contract agreement