We calculate `total float`

through a simple algorithm called backward pass. In effect, we start from activities that have no successor activities (*leaf* activities), and recursively work backwards. Each leaf activity receives a `total float`

that is equal to the time difference from the activity finish date to the Must-Finish-By-Date of the project.

For each step in this recursion, the predecessors’ `free float(s)`

is updated with the minimum between their current `total float`

value and the new candidate `total float`

(sum of the reference node’s `total float`

plus the relationship `free float`

between reference and its predecessor).

This may sound complicated but it is the fastest way to compute `total float`

- we find that drawing it on a piece of paper with a simple example always helps :)

Calendars are taken into consideration through the computation of all relationship free floats. Depending on the relationship type (FS/FF/SS/SF) and the value of the lag, the start/finish date of the predecessor and the successor are used to compute the free float of a specified logical dependency using the *predecessor’s calendar*.

Consequently, calendars are taken implicitly into consideration within TF calculations via the input (free floats) to the backward pass procedure.

When calculating `total float`

, completed activities have no effect on the calculation of `total float`

of downstream activities which are either in progress or planned. Specifically, completed activities and all logical dependencies stemming from, or pointing to, them are removed from the `total float`

calculation. These activities are subsequently assigned a `null`

value. The outcome of this method is consistent with the results of other established scheduling tools like Oracle Primavera P6.

We take the impact of constraints to calculating `total float`

by default. Specifically, when an activity has a constraint that impacts its finish date (i.e. a *hard constraint on its finish date)*, a `total float`

of zero is assigned.* *The outcome of this method is consistent with the results of other established tools like Oracle Primavera P6.

Our backward pass algorithm is compatible with the default way Oracle Primavera P6 operates, which is called the Finish Float approach.

Under the Finish Float approach, the `total float`

of an activity is defined as the Late Finish - Early Finish float entry.

Negative `total float`

is defined as the amount of time that must be saved in order to bring the project up to speed so that it is not delayed by the activity that has that `negative float`

. Negative relationship free float refers to the number of days that an activity will delay its successor activity.

In scheduling software (incl. Oracle Primavera P6) `negative free float`

- and consequently `negative total float`

- is triggered by either of the two:

- The finish date of the latest ending activity is later than the Must-Finish-By Date of the project set by the user.
- A constraint has been introduced, which has overruled the pre-defined relationships among activities.