Total Float Challenge

I’ve offered the LinkedIn community to solve a scheduling challenge: calculate the Total Float (TF) for activity B in the following scheduling fragment.

The responses varied widely, producing four different answers:

• Some said TF was positive but disagreed whether it was 1 or 3 days.
• Others argued it was negative (–2 days).
• Some concluded TF was exactly 0 days.

The truth is that each answer is technically correct, depending on the perspective taken. The problem is that there’s no agreement on which perspective is the “right” one.

Popular scheduling tools don’t provide visibility into these multiple perspectives. Even though some participants correctly noted that the result depends on the chosen definition of TF, in practice, only one value is usually calculated, analysed and reported. And since all delay claim methods treat ‘Total Float’ as a universal, commonly agreed metric, the lack of clarity creates serious risks.

There is no single, universally accepted definition of TF. While the published definitions may look similar, subtle differences lead to very different results.

There are at least four valid perspectives to analyse the impact of activity delay:

1. Delay of activity start in relation to the project forecast date(s).
2. Delay of activity finish in relation to the project forecast date(s).
3. Delay of activity start in relation to the project deadline date(s).
4. Delay of activity finish in relation to the project deadline date(s).

Each perspective is valuable and complements the others. Trying to use one metric to represent all four inevitably leads to miscommunication, poor project decisions, and incorrect claims.

Let’s call each perspective:

• Total Float Start (TFs),
• Total Float Finish (TFf),
• Recovery Gap Start (RGs),
• Recovery Gap Finish (RGf).

The correct answer is: TFs= 0d, TFf = 3d, RGs= -2, RGf = 1

While definitions of TF vary, it always includes the ‘time activity can be delayed’ statement, and it is impossible to delay something to a negative period. So, Total Float can’t be negative.

So, it would be better if planners use a different term for the metric that is not associated with Total Float. For years, I was thinking of a good term for that metric and stick with RECOVERY GAP (RG).

This is not difficult to understand and calculate!

However, the new metric only partially solves the ambiguity of the TF definition. To address the challenge, the project management field must first build a proper taxonomy. Terms like constraint, delivery date, delay, duration, resource, dependency, etc. have multiple meanings, and any definition based on these terms will lead to debates.

Scheduling systems should not be methodologically agnostic! They must be based on clear definitions.

Now the catch:
For decades, all historical scheduling data, and now GenAI systems have been developed based on that mess.

There are multiple root causes:

• Project management lacks a proper taxonomy. Key terms are ambiguous.
• Mainstream tools like Primavera (P6) and MS Project (MSP) are outdated, incapable of handling multiple float types. New systems (OPC, Alice Technology, PlanLab, etc.) are methodology agnostic and replicate P6 & MSP capability gaps.
•  Scheduling guidelines and recommended practices contributors are biased towards systems they personally used, and it is almost always one of the listed above systems.
• No certification program requires schedulers to study network analysis methods beyond the basics.
• Forensic consultants, focused on claims and biased toward specific metrics.

• Develop taxonomy. It would require the creation of new terms, as existing terms are used in many ways, and we can’t change that.
• Enhance the Network Analysis methods with scope, resources, risks, and benefits. Develop a set of schedule analysis and optimisation metrics supported by heuristic-based calculations. It will require collaboration with Academia.
• Develop advanced scheduling guidelines. It can’t be done by volunteers. It requires effort from real experts, and they must be well paid for that effort.
• Develop training and certification programs.
• Develop scheduling systems that support schedule analysis metrics. It requires investments and collaboration between practitioners, system development and academia.