Total Float Challenge: a deadline with positive Float

Total Float Challenge: a deadline with positive Float

by | 30 Oct, 2025 | Blog

The previous Total Float challenge demonstrated that the lack of a clear, unambiguous definition of schedule analysis metrics may lead to poor project decisions. This challenge was initiated to demonstrate that Critical Path Method exist in different, not aligned realities:

  • Theoretical CPM
  • Practical CPM
  • Software(s) CPM

I invited the Planning and Scheduling LinkedIn community to take on the next challenge: find the Total Float for one of the activities in a scheduling fragment.

I took the previous challenge as the base and increased the complexity by adding two pitfalls:

  1. Positive period against the deadline.

There is a 1-day gap between the forecast milestone delivery (13 days) and the contractual deadline (14 days).

  1. Activity continuing past the deadline.

An additional activity occurs after the deadline, which is a common situation in many projects.

Although these nuances appear minor, they fundamentally affect how the Critical Path is identified. The challenge proved difficult; no one could clearly explain why the practically correct answers differ from those produced by CPM software. Let’s explore why this is the case.

Practical CPM Perspective

Many participants gave the “right-looking” answer: start of Activity B can be delayed for one day without missing the deadline. Some went further, noting that its duration could extend to three days without impacting the deadline. Keep these two numbers in mind -we’ll revisit them soon.

However, in the CPM method Total Float metric measures float relative to the forecast finish, not deadlines. This point, already discussed in the first challenge, is highly contentious, as many CPM systems mix all perspectives into a single metric.

Some planners reviewed the challenge from a forecast perspective and concluded that Activity B has zero float (TFs = 0d) and lies on the critical path, since delaying its start extends the project to 18 days. Others added that it could be extended to two days without affecting the project finish (TFf = 2d).

Critical Path in this fragment: ABD(milestone)E

Delaying start of each activity on this path will delay the milestone (13 days) and end project date (18 days). Factor the forecast and deadlines into the calculation, we can conclude that:

Total Float values should be TFs = 0d and TFf = 2d.

Recovery Gap values should be RGs = 1d and RGf = 3d.

Recovery Gap (RG) is a network analysis metric that quantifies the time required to bring activity back on track to meet one or more project targets. A negative RG value indicates that schedule acceleration is needed. A positive value indicates available float.

But here is the catch: popular CPM tools don’t calculate metrics in that way! 

Software(s) CPM Perspective

If we model this scenario in Primavera P6, Microsoft Project or Spider Project results will be different:

RGs = 0 days, not 1 day as practitioners suggested. TFf and RGf can’t be calculated in Primavera P6 and MS Project systems!

As in Primavera P6 and MS Project is impossible to model TF and RG simultaneously I will perform separate computations.  

Scenario with the deadline modelled in Primavera P6.

Scenario without the deadline modelled in Primavera P6.

Scenario with the deadline modelled in MS Project.

Scenario without the deadline modelled in MS Project.

Scenario modelled in Spider Project.

  • Negative Float metric represents RGs
  • Float Super metric represents TFf 

In all scheduling systems RGs is Zero days (not one). None of systems can calculate RGf (3 days).

Based on CPM scheduling systems, Recovery Gap Start for activity B are different from the practically correct answers.

What CPM Tools show different result?

The fragment contains a second, hidden deadline – the project end date at 18 days.

This deadline is generated during the forward and backward pass calculations and serves as the basis on which CPM tools determine Total Float.

In practice, projects rarely treat the last activity’s finish date as equally critical to every other contractual or business-driven deadline. Yet CPM logic assumes it is.

This leads to misleading outputs – activities that appear critical in the model may, in fact, may have positive Recovery Gaps in reality. As a result, project decisions and claims based on such analysis can be flawed.

This is one of the reasons why schedules used for forensic or predictive analysis often fail to represent project reality. Planners and schedulers tend to place full trust in CPM tool outputs without realising that the underlying logic and hidden assumptions in these systems can distort actual project realities.

Summary

The Critical Path Method is often regarded as a well-defined and consistently applied approach. In reality, it exists as a family of related methods – one described in textbooks and guidelines, another implemented in scheduling software, and yet another practised by planners in real projects.

Even a seemingly simple question like “What is the Total Float for a single activity in a small schedule fragment?” can become surprisingly difficult to answer, as the result depends on which version or perspective of CPM we choose to apply.

The pitfall discussed in this article is only one of several reasons why CPM calculations can yield inconsistent results. It has direct practical importance for predictive schedule analysis and for forensic investigations of project delays.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

Total Float Challenge

Total Float Challenge

by | 18 Sep, 2025 | Blog

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.

If this were a real project, how would such differences affect project decisions and claims?

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.

Challenge Solution
On the surface, the problem looks mathematically simple, but the real complexity comes from ambiguity in the definition of Total Float, not the mathematics behind it.

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

Recovery Gap

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.

‘Negative Float’ is a complete oxymoron.

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).

Recovery Gap is a network analysis metric that quantifies the time required to bring an activity back on track to meet one or more project targets. A negative RG value indicates that schedule acceleration is needed.

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.

What sort of GenAI Scheduling are we talking about if the best planning and scheduling consultants on that planet can’t answer a simple question: what is TF for one activity in the small schedule fragment?

How did we get here?

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.

How to address the challenge?

  • 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.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

Total Floats: with or without project deadlines.

Total Floats: with or without project deadlines.

by | 8 Jan, 2023 | Blog

One of the most important outputs of the Critical Path Method (CPM) is a calculation of activities Total Floats (TF). However, there is no commonly agreed approach to calculate TF when the project has deadlines. Different project management tools have different features to manage deadlines and the ways they calculate TF.
Should the deadlines be a part of the calculation or not, and why?

Spider Project provides both perspectives simultaneously. Primavera (P6) and Microsoft Projects users have to choose which type of calculation they prefer. For effective project optimisation and control, it is very important to be aware of both perspectives. This post explains how scheduling tools calculate TF with deadlines and how additional Critical Path  Metric: “TFD: Total Float Deadline” could be developed in P6 and MSP.

Critical paths without project deadlines

Critical Path calculates the sequence of project activities by taking into account the following project constraints:

  • Technical (business process) dependencies;
  • Activity and resource calendars;
  • External incoming dependencies;

Other types of constraints: resource dependencies, material supply and financial limits could also be added but related dependencies have to be identified manually or with a scheduling tool that supports Resource Critical Path. 

Additionally, projects may have situations when all prerequisite conditions have already been achieved, but the activity is still not able to commence. For example, training is scheduled to start next month. In theory, such a constraint could be added as an activity calendar constraint but practically it is not convenient to create a new calendar for each ‘Start Not Earlier Than’ (SNET) constraint presented.

It is much easier to add the SNET constraint to the related activity.

SNET constraints are required as sometimes activity could not commence earlier even though all predecessors completed.

All constraints in the classical critical path are from the Left side of activities or milestones. As a result, the Negative Total Float is impossible as nothing constrains activities from the right.

Total Float with project deadlines

A project deadline represents a desired target date. This target is represented by the ‘Finish No Later Than’ (FNLT) type of constraint, which is always from the RIGHT side of an activity or a milestone.

  • The deadline could be put to the end of the project or an intermediate milestone, for example, the ‘Go-live’ date
  • A project may have one or many deadlines, for example: ‘Output N1 implemented’, ‘Output N2 implemented’, etc.

Schedules with deadlines may have activities with Negative Total Float if the deadlines are taken into analysis.

Which type of Total Float is more important?

Both types have advantages and disadvantages, and it is very important to analyse both perspectives!

Total Float

Total float is the total amount of time that a schedule activity may be delayed from its early start date without delaying the project finish date, or intermediary milestone.

A Project Critical Path allows seeing the true Total Float (Total Slack in Microsoft Project):

How many days (or hours) could an activity be delayed before it imposes a delay on the project END date or at least one of the DEADLINEs is impacted?

Based on the above definition, TF could not be negative. Only zero or positive. However, it is useful to know how an activity is progressing against project targets as well. If an activity has negative TF, acceleration is required. If the TF is positive, it has a contingency.

On the other hand, if we allow TF to be negative, it would be much harder to understand which activities are on the project’s critical path.  A critical path with imposed deadlines may have all project activities with positive or negative Total Float.

Critical Path Example

Let’s review the next project. It has 3 streams of works: ABF, ACDF and AEF. All dependencies are finish-to-start.

Without calculating a critical path, it is not easy to understand which activities have a contingency (aka Total Float or Total Slack).

The Project Critical Path gives us answers to the next questions:

  • Which activities drive the project completion date?
    It is very easy to understand that: activities with TF=0 are critical: ABF
  • When the project is going to be completed?
    Answer: in 18 days, 24th of the month.
  • How much contingency non-critical activities have?
    Activities with TF > 0 have next TF: C = 3 days, D = 3 days, E = 5 days

Now assume that this project has a deadlinea and activity F have to be completed by 22nd.

How is the CP calculation going to change if the deadline is added to the schedule?
The Critical Path will be the same: ABF

Would the Total Float now be different? Different scheduling tools give different answers to question!

Critical Path in the context of the (22nd) deadline:

Now, when the schedule has positive and negative Total Floats, it is not easy to understand which activities drive the critical (ABF) path and what is the REAL size contingency non-critical activities have.

What if activities C or D are delayed for 2-3 days? It delays the project end date ONLY if any of the critical activities A, B or C could be accelerated! Otherwise, this delay will not impact the CURRENT delivery date.

It is very important to know both perspectives: Project Critical path and Dealine Critical Path! 

Unfortunately, Primavera and Microsoft Project users have to decide which perspective is more important for them and stick with the approach.

Once, while performing schedule analysis, I’ve asked myself, is there a way to see both perspectives in these tools? With some tricks I have found workarounds that is explained below.

Deadlines in scheduling tools

Let’s review how popular scheduling tools calculate Total Float with Deadline dates.

Primavera, Microsoft Project and Spider Project have completely different features to manage project deadlines and calcualte Total Floats.

Spider Project

In Spider Project, deadlines could be added on a project level or an activity level.

Project Deadline:

Spider Project (SP) allows adding SNET and FNLT constraints for any activity or milestone.

Based on the TF definition it could not be negative! This is exactly how Spider Project calculates it. The SP CP algorithm takes all constraints into the consideration, and if an activity doesn’t have an available contingency, TF will be zero.

If a user wants to know TF in the context of deadlines, there is another metric- Float Negative, that shows how many days (or hours) the activity is ahead or behind schedule.

Both metrics could be shown in Gantt Chart Report.

This is what we need but how we can get similar metrics in P6 and MSP? 

Microsoft Project

Microsoft Project has two options to set deadlines: by using constraints or the ‘Deadline’ feature.

The first option would be to use a ‘Finish No Later Than’ (FNLT) constraint.

However, such date enforcement may cause schedule conflict, and the project completion date will be incorrectly shown as 22/05/2023.

All constraints in Microsoft Project (excl. ‘Start No Earlier Than’) must be avoided. 

ASAP and ALAP are not constraints but activity priorities. It is unclear why Microsoft mixed up these two concepts.

So, if constraints are not recommended, how to set up Deadlines then? Microsoft has an important advantage over Primavera: the Deadline feature!

Instead of adding a deadline as a constrain date, MS Project has a separate Deadline field for that:

In this case, the project completion date will be driven by logic, and Total Slack is calculated in the context of project deadlines.

The Microsoft Deadlines don’t impact the calculation of the critical path but the impact calculation of Total Slack only.

We have found a good way of calculating the critical path correctly and understanding the Total Slack but lost the opportunity to understand the true Total Floats.

As a workaround, project deadlines could be stored in a custom field (Date), and Deadline Total Slack is stored in a separate custom field (Number).

TotalSlack Deadline Metric:

We store the deadline date in the DeadlineDate field instead directly in Deadline:

When we want to know Total Slack in the context of deadlines, we copy the deadline date to the Deadline field, recalculate TF and store the result in the custom ‘TotalSlack Deadline’ field.

Then, deadline dates are removed from the Deadline field, and the user can see both types of Total Slack: with and without deadlines!

By creating Microsoft Project Macro, this process could be fully automated:

Sub TotalSlackDeadline()

‘ Macro Created 7/01/2023 by Alex Lyaschenko.

‘ Custom Field ‘Date1 (DeadlineDate)’ stores Project Deadline Dates

‘ Custom Field ‘Number1 (TS Deadline)’ store Deadline Total Slack

    SelectRow Row:=0, RowRelative:=False

‘ Copy Dates from DeadlineDates to Deadline

    SelectTaskField Row:=0, Column:=”Date1″, RowRelative:=False, Height:=7

    EditCopy

    SelectTaskField Row:=0, Column:=”Deadline”, RowRelative:=False

    EditPaste

 ‘Switch On formula Number1 = [Total Slack]/480 (8h per day)  

    SelectTaskColumn Column:=”Number1″

    CustomFieldPropertiesEx FieldID:=pjCustomTaskNumber1, Attribute:=pjFieldAttributeFormula, SummaryCalc:=pjCalcNone, GraphicalIndicators:=False, AutomaticallyRolldownToAssn:=False

‘ MSP automatically calculate Deadline Total Slack

‘ Switch Off the formula

    CustomFieldPropertiesEx FieldID:=pjCustomTaskNumber1, Attribute:=pjFieldAttributeNone, SummaryCalc:=pjCalcNone, GraphicalIndicators:=False, AutomaticallyRolldownToAssn:=False

‘ Delete Dates from Deadline fields

    SelectTaskField Row:=0, Column:=”Deadline”, RowRelative:=False, Height:=7

    EditClear Contents:=True

End Sub

Primavera

Primavera doesn’t have a similar to Microsoft Project the deadline feature, and activity deadlines could only be organised via constraints.

Primavera has 9 (!) types of constraints, and it is not intuitively clear what is the key difference between them. Often planners don’t apply them incorrectly. It is probably one of the biggest factors that impact the quality of Primavera schedules.

As discussed above, there are only two genuine types of constraints: NET (Start on or After) & NLT (Finish On or Before). The rest is a ‘scheduling noise’ that impacts the quality of schedules.

Primavera has four ‘Finish’ constraint types. Constraints impact the calculation of the critical path and the TF differently.

  • Finish On or After
    This constraint type should be represented by the ‘Start On or After’ constraint, plus the activity duration or activity type changed to ‘Level of Effort’.
  • Finish On or Before
    FOOB constraint is the same as ‘Finish No Later Than’ constraint in Microsoft Project and the ‘NLT’ constraint in Spider Project.
  • Finish On
    It shouldn’t be applied as it may cause a schedule conflict.
  • Mandatory Finish

    It shouldn’t be applied as it may cause a schedule conflict.

A deadline, ‘Finish On or Before’ constraint doesn’t cause schedule conflict but impacts TF  calculation.

This constraint type could be used for calculating TF in the context of project deadlines. However, if such constraints are applied, it is impossible to understand the true TF!

As a workaround, project deadlines could be stored in the Deadline field, and an additional Critical Path Metric: ‘TF Deadline’, is calculated only when detailed Critical Path analysis is required.

  • When a Primavera user wants to see the true Total Float, all ‘Finish On or Before’ (FOOB) constraints should be deleted. It is easier to do by Global Change. 

When the user additionally wants to know TF in the context of deadlines, they can automatically copy the deadline dates from the Deadline Field, recalculate the critical path, copy Total Float to the TF Deadline field and Remove all FOOB constraints.

Add Deadlines as FOOB Constraints:

Primavera’s Deadline field, compared to Microsoft Project, only displays the Deadlines in Gannt Chart and doesn’t impact TF.   

Copy TF to TF Deadline field:

The result of the calculation is stored in the separate TF Deadline field. So, it is possible to see both types for Total Float, with and without deadlines.

Summary

One of the greatest advantages of the critical path method is the ability to understand the available contingency for each activity in the project. However, the contingencies could be calculated with and without project deadlines. For effective project planning and control, it is important to know both perspectives.

Popular scheduling tools have different features to manage project deadlines that impact the calculation of critical paths and Total Floats.
Spider Project provides both metrics simultaneously.
Primavera and Microsoft Project users have to decide which perspective is more important for them.

With proposed workarounds, users can have an additional Critical Path metric: Total Float Deadline and understand both perspectives simultaneously!
The additional metric is important for effective project control and forensic analysis.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma