Total Floats: with or without project deadlines.

Total Floats: with or without project deadlines.

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


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


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


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

Schedule Quality Metrics. Out-of-sequence Activities

Schedule Quality Metrics. Out-of-sequence Activities

One of the important schedule quality metrics is ‘out-of-sequence activities’.

“Out of Sequence Activities” (OOS) – a result of executing the works without following the logic as planned.

There are many very good posts that explain what is “Out-of-sequence activity”, “How to identify them” and even “How to remove them from the schedule”. I am not going to repeat that. You can find links to these posts below.

The questions that I wanted to discuss in this post are:

  • Why do projects have out-of-sequence activities?
  • Is it good or bad to have them?

Why do projects have ‘out of sequence’ activities?

The short answer to this question: the plan was wrong. However, there are GOOD and BAD reasons why the plan was wrong:

GOOD reason: The project team is agile.

A project may have OOS activities if teams working on site find a better way of doing things and the project manager/planner didn’t think of it first. Planning guru Rafael Davila from Puerto Rico once said: “If you have out-of-sequence working it does not necessarily mean it is a planning error, it is common when you plan to avoid too many people working at the same time in the same place and then during the course of the job you find out it is convenient to reduce the waiting time. Life and construction works are complicated, pretending to model such with only FS relationships is a utopia.”
Any project has stable technical (business process) and not stable non-technical dependencies to address resource, material, financial and space constraints. If a project delivery team is agile (yes, even construction projects could be agile!) they are constantly looking for an opportunity to remove non-technical dependencies and commence work earlier.

BAD reason: Schedules don’t apply correct logic.

Most project managers and schedulers are aware that there are 4 primary types of schedule dependencies: Finish-to-Start (FS), Start-to-Start (SS), Finish-to-finish (FF) and Start-to-finish (SF). Recognised project management and scheduling standards (PMBoK, APM Body of Knowledge, Praxis Framework, etc) explain each type but somehow miss one critical point:

Four types of project dependencies are mutually exclusive. It is not possible to create a simulation of one type by applying another type correctly.

If a business process requires the application of, for example, SF dependency the scheduling fragment could not be correctly simulated by replacing the SF dependency with FF, SS or SF types.

Next time when you notice that project (or portfolio) scheduling guidelines recommend to minimise the application of SS and FF dependencies and prohibiting the application of the SF type be sure:

  • A Schedule is not going to be used to drive project delivery. Maybe only for reporting.
  • It is going to be many ‘out of sequence’ activities when the progress is collected.

The quantity of SS, FF and SF dependencies depends on the nature of the project. Some projects are going to have more parallel and overlapping activities than others.

It is not possible to define strict percentage targets and claim that the schedule doesn’t have the decent quality only because there are more than 1X% of other than FS dependencies.

DCMA-14 points Schedule Health Assessment

DCMA-14 points metric N4: ‘Finish-to-Start relations’ often get misinterpreted. This is one of many examples (
“The finish-to-start relationship provides the most explicit presentation of the project schedule activities. The other types of relationships, which can be identified in a schedule, are finish-to-finish (FF), start-to-start (SS), and start-to-finish (SF). However, it is not recommendable for these to be used since they are harder to monitor and control.” 

What this metric is actually showing is that a schedule with a high percentage of other FS dependencies requires higher attention. It doesn’t mean that schedules don’t have low quality. There could be valid reasons why there are more than usual SS, FF and SF dependencies or maybe the project is applying SS instead of FS to hide project progress. The reasons must be discovered and accepted.
Also, if a schedule has a very high percentage (some have 100%) of FS dependencies, it is a great candidate for a deep schedule review. It is likely that the project doesn’t have an experienced planner, or the planner is forced to follow low-maturity portfolio standards.
If a schedule has 100% of FS dependencies ‘DCMA 14-points’ incorrectly shows that this metric is ‘Green’, when it should be flashing red.

The quantity of SS, FF and SF dependencies depends on the nature of the project. Some projects are going to have more parallel and overlapping activities than others.

It is a misleading metric and should not be applied blindly.

BAD reason: level of details

Some schedules don’t have the right level of detail. Planned sequenced activities are actually overlapped. In this case, the project may consider completing decomposition or adding lags and leads.


Another reason why projects may have out-of-sequence activities is fast-tracking.

Fast Tracking [Technique]. A specific project schedule compression technique that changes network logic to overlap phases that would normally be done in a sequence, such as the design phase and construction phase, or to perform schedule activities in parallel. (Practice Standards for Scheduling, PMI)

Fast-tracking is always associated with risk. If a project team took this risk and started the successor activity earlier by breaking the technological process, the question that needs to be asked is: “Has this risk been analysed, and if yes, why is the schedule not updated?”. If the analysis was completed without schedule-based what-if analysis, it indicates that the project doesn’t have schedule and risk management integrated.

Scheduling Tools

Projects managed in Primavera and Microsoft Project are likely to have more out-of-sequence activities for the bad reasons. There is still no front-end access to the dependency table, only via the back-end and it is not possible to differentiate a type of dependency in these tools. So, for planners, it is much harder to change logic as they don’t know which dependencies are technical dependencies and should not be touched (unless it is approved fast-tracking), or if it is a dynamic resource dependency.

Primavera recently added a ‘dependency note’ feature, but for large organisations, it would take years to update for the planners to have access to this feature.
Also in Primavera, it’s not easy for P6 planners to change future logic, they focus more on progress updates.

Schedules managed in Spider Project typically have fewer OOS activities as broken dependencies could be easily identified within the tool. Spider Project has front-end access to the dependency table and a powerful filtering mechanism. 

OOS Types

As there are four types of dependencies, there are also four basic examples of how the activity could be OOS. However, as an activity may have lags and leads there are other, more complex scenarios of OOS logic.

It is important to identify all OOS cases, not only broken FS dependencies.


  • Out-of-sequence activities represent broken logic.
  • There are good and bad reasons why projects may have OOS activities.
  • OOS logic has to be identified and fixed including other than FS broken dependencies.
  • It is very important not just to fix already broken logic, but also to analyse why the project has broken activities and, if required, apply changes to the outstanding activities and mature schedule management processes.

Useful links:

Alex Lyaschenko

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