TOTALFLOAT Calculation - Not tied to Critical Path?

Rob W.

Hi all,

I'm looking to rely more on calculated row float to inform my project teams how much flexibility we have on event completion dates relative to impacting critical path. I found the following function and baked this into our standard schedule template:

=TOTALFLOAT([Task Name]@row)

After working with this for a while, I noticed some odd behavior and decided to do some sandbox testing to see if I can figure out what's going on since I don't have much visibility into the mechanics of the TOTALFLOAT function.

In my test schedule, I start with a clean critical path of sequential tasks:

When I add nested tasks (Task 1 and Task 2), these automatically carry the logical predecessor / successor logic of the parent task (Phase 3), and show up on the critical path without manually tying direct predecessor / successor row logic. Good.

However, the float calculation doesn't follow. With both tasks 1 and 2 being 10d duration, they're equally critical path and should display 0 float. I can accept that the critical path check has to pick one and defaults to the earlier row entry, but I can't accept the float shown for task 2 (40d). If I extend the duration by 1 day, task 2 becomes critical and task 1 now has 41d float:

If I then manually translate the successor logic for Phase 4 to be rows 5, 6, & 7, now I get accurate float:

On complex schedules with hundreds of rows and multi-level nesting, I have to be able to rely on the hierarchy and both row and parent-level logical ties to inform float calculations, otherwise this becomes an administrative nightmare.

It would seem that the critical path function is using the right variables and effectively just applies a true / false flag for float = 0, so I'm struggling with why the TOTALFLOAT function isn't effectively the exact same operation just reporting out the numeric delta between forecast finish and the critical path successor.

Hoping there's some modification I can apply to the TOTALFLOAT formula I'm using to factor in proximity to critical path. Thanks in advance for any suggestions!

Genevieve P.

Hi @Rob W.

This has to do with the Parent/Child relationship and the Critical Path. Parent rows are an automatic "summary" of the Child rows below, taking the earliest Start Date as the start and the latest End Date as the end. (See: Parent Rollup Functionality)

This means that if there's a predecessor or dependency tied to the Parent row, this effects whichever of the children has the last end date, as that's the defining end date for the Parent row. That puts it on the Critical Path, and the Total Float can calculate.

However if there are any rows in your project without a tie to a Predecessor or Dependency, then the TotalFloat sees this as being able to float within the entire project, until the final end date (e.g. 40 days). There are no tasks that are dependent on this row at all, so it has no criteria for when it has to be done by, other than the end of the project. This is seen as true even if that row is a Child row. In the Gantt chart, there are no lines at all between that blue bar and any other bar in your project.

In your instance, your test Child row is only synced with the Parent row once there was some sort of connection between that task and any other tasks: when you added row 6 as a Predecessor to row 8. Now row 6 can only float until Phase 4, the row it's connected to.

This is currently expected behaviour. Best practice in this scenario would be to add Predecessors to each Child row (skipping the Parent, as that will be defined by the Child rows).

Cheers!

Genevieve