NEC3 Programme Terminal Float

We observed that the Contractor had set the Terminal Float to 0 (planned Completion = Completion Date) since the very first submitted programme. Since then, every revised programme showed a delay. This becomes a problem that everything seems to be critical and difficult to monitor the progress. Yet, the first programme (with 0 Terminal Float) was accepted, so we cannot undone and no NEC clause says they cannot do it.

What’s the trick/benefit for the Contractor to set his Terminal Float to 0? For having higher probability to get more CE (EOT/Money) ?

1 Like

The Completion Date and Planned Completion should be independent of each other. The first is effectively a target. The second is whether you think you will hit the target or not. Your statement that ‘everything seems to be critical’ is a bit worrying - it suggests that Completion Date is being used as a constraint in the programme, which it shouldn’t be.

As for process, there is nothing intrinsically wrong with the two dates being the same.

I don’t see any particular advantage to having zero terminal float, because extensions of time are assessed as the delay to Planned Completion, not the delay to the Completion Date. Therefore if a CE happens here and the Contractor had no terminal float before, they should still have no terminal float afterwards.

4 Likes

Hi

The absence of terminal float in the first programme should have been cause to reject it.

You also omitted to mention if the programme contains time risk allowances (as the absence of TRA in an accepted programme is a bigger problem).

Your question also suggests you think that Terminal float can be used up by the PM to avoid moving the completion date.

If there is no TRA or terminal float, then the PM needs to record all delays incurred by the contractor for risks that he has accepted (breakdowns, absenteeism, weather, ground risk etc).
In each revision of the programme, the PM is entitled to have these delays shown on the programme in order to accept it.

But if both parties want to work together, you need to have a workshop and fix the programme to make sure it includes TRA and terminal float. That way ye can both live with a programme and get back to working collaboratively to deliver the project by the completion date.

I agree that the absence of TRA’s is indicative of problems, but its not one of the grounds for withholding acceptance in Cl 31.3, and nor is the absence of terminal float.

If there is no terminal float it is in nobody’s interests to force the Contractor to show one - the whole point is that the programme should represent the truth.

TRA’s are complex. There is no one way to manage them, and as far as I know there is no accepted norm for how they should be used. Some Contractors will programme optimistically and use TRA almost everywhere, almost to pull the programme back to something more realistic. Others will programme realistically / conservatively and only use TRA on high risk or difficult things. Either is valid.