Critical path method challenge: Activity duration estimation

Critical path method challenge: Activity duration estimation

by | 5 Mar, 2023 | Blog

The critical path method includes several standard steps. While there are different recommendations in which order these steps need to be performed, it is a general acceptance that one step is important: the duration of each activity has to be accurately estimated.

The activity estimation is a process itself. The process could be very simple.

“Using past experience or the knowledge of an experienced team member, you must now estimate the time required to complete each activity.”
www.smartsheet.com/critical-path-method

or more complex:

“The duration is an estimate of how long it will take to accomplish the work involved in the activity. In many cases, the number of resources that are expected to be available to accomplish an activity, together with the productivity of those resources, may determine the activity’s duration. A change to driving resource allocated to the activity will have an effect on the duration, but this is not a simple “straight-line” relationship. Other factors influencing the duration are the type or skill level of the resources available to undertake the work, resource calendars, and the intrinsic nature of work. Some activities will take a set amount of time to complete regardless of the resource allocation.”
Practical Standard for Scheduling, PMI

How can an estimator/s accurately provide estimates for the duration of ONE activity? Is it actually possible?

Firstly, they need to understand the work represented by the activity in the schedule. Ideally, the Definition of Done (DoD) for each activity has to be developed, but it is rarely the case. Usually, estimators rely on activity and WBS names only.

Example: “Complete Design” could mean:

  • 1st draft available
  • Design reviewed
  • Design updated
  • Design submitted for review board
  • Design endorsed
  • Design fully approved

Then, estimators need to understand the level of uniqueness of this activity. It may vary from ‘exactly the same work was done before many times’ to ‘this work is completely new to us’.

Then, estimators need to think about matters that may impact the duration:

  • What is the Volume of work to be achieved?
  • Which skills are needed?
  • Which resources have these skills?
  • Could additional skilled resources be hired?
  • What is the minimum (technically) required number of resources?
  • What is the maximum (technically) possible number of assigned resources?
  • What productivity (volume units per hour) does each resource with the required skill have?
  • If more than one skill is required, which skill has the primary impact on the duration?
  • When could the activity be (technically) performed?
  • How may external work impact the availability of resources?
  • How may other project activities impact the availability of resources?
  • What type of materials are required?
  • How may materials supply impact the duration?
  • How may project’s environmental factors impact the duration?
  • How may external factors impact the duration?

Translating these questions to a scheduling language: there are project parameters that may impact activity duration. Some of these parameters could be well-known or they may have avoidable (epistemic) or unavoidable (aleatory) uncertainties (U). Also, some of these parameters are interrelated (I) with other activities.

  • Volume of work (U)
  • Skills (resource pool)
  • Renewable (Labour and Equipment) Resource Quantity (U, I)
  • Consumable (Materials) resources quantity (U, I)
  • Resource Productivity (U)
  • Activity Calendar (U)
  • Resources Calendars (U)
  • Resource availability (A)
  • Technical constraints (U)
  • Threats (I)
  • Opportunities (I)
  • Shift calendars (U)
  • Shift quantity (U)

It is usually easy to understand how each parameter impacts the activity duration but it is not easy to understand the cumulative effect. The human brain is simply not able to handle so many parameters simultaneously. If George A. Miller’s statement is correct#, our brains can handle only 7 (+/-2) objects simultaneously.

# The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information http://psychclassics.yorku.ca/Miller/

It is important to mention that not all activities have all mentioned above parameters, or a value could be obvious and even ignored:

  • Activities may not include any materials
  • Only one resource with standard working hours is required
  • An activity technically could be performed at any time.

There are different project techniques that could help with estimations:

  • Top-Down
  • Bottom-Up
  • Expert judgment
  • Comparative (or analogous)
  • Parametric model
  • Three-point

These techniques help to get accurate estimations but they have to be applied to primary parameters that impact durations, not directly to durations.

Example:

Our project received a new bulldozer. It differs from other bulldozers used in organisations, so we don’t have any statistical data to understand the productivity rate. Project decided to use comparative analysis (or Expert judgment) as a planned rate and calculate activity durations based on this rate. When they receive actuals, they can update the productivity rate and recalculate all future activities with the assigned of this bulldozer. Also, if the productivity rate is stored in Corporate Reference Book, they could update other projects where this bulldozer is planned or use the findings for future assignments.

If activity durations were collected instead, it would be very difficult to recalculate and update all related activities, as they would need to be done individually. Also, historical data is (almost) useless. While we know that actuals were different from planned durations, there is no data in the schedule that tells us “why”, and it is hard to reuse historical data for future projects.

Expert judgment

Expert judgment often is only available for project teams as an estimation technique.

Unfortunately, expert judgment is not a reliable method. Daniel Kahneman in his book “Thinking Fast And Slow” explained that when people need to find a solution to very complex problems, they are likely to use a “fast thinking system” that could give them quick but not necessarily accurate answers. What is even worse, the answers are inaccurate and inconsistent. If the same expert provides activity estimations in a week, it is likely that his estimations would not be the same. Different cognitive biases may impact their opinion. In some cases, provided estimations are going to be very conservative. In other situations, they will be too optimistic.

What is the alternative

Stop asking estimators to provide most likely activity durations and ask them to provide parameters that impact this duration instead.

If a parameter has an uncertainty, usually it is much easier to provide a range or 3 points (optimistic, probable, pessimistic) rather than a single number.

Then all available data could be used to calculate the optimistic, probable, pessimistic and planned durations!

This approach has some advantages:

  • Easier identification of why an activity wasn’t performed as planned
  • Collected actuals could be used for planning for future activities even if the activities are not exactly the same:

    * Activity requires the same skill but has a different volume of work.

    * Activity has the same volume of work and skills but will be performed by different resources.

    • Some of the activity parameters are applicable to many activities, so once collected the data could be used for many activities
    • While a project may have thousands of activities, it doesn’t require thousands of skills. Even a project-driven portfolio has a small and stable list of required skills.
    • Easier identification of project and portfolio skills bottleneck
    • Each resource has a very limited number of skills. It could be beneficial to help critical resources gain a new appropriate skill or improve already existing skill
    • 3 points estimations could be used for more sophisticated probabilistic methods: Monte Carlo Simulation, ‘3 scenarios’, etc.
    • Result of the Monte Carlo Simulation depends on the simulation parameter. The result of the simulation is more accurate when primary uncertainties are used instead of the secondary parameters (like duration and cost)
    • Structured low-level data could be used for AI
    • It addresses some cognitive biases. Just a few to mention:

    * Optimism bias

    * Representativeness bias

    * Confirmation bias

    * Framing effect

    * Parkinson Law

    * Availability heuristic

    Alex Lyaschenko

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

    Resource vs activity calendars issue

    Resource vs activity calendars issue

    by | 22 Feb, 2023 | Blog

    Correct application of the Critical Path Method requires consideration of ALL constraints. A calendar is a ‘type of constraint’ that defines when work can and cannot be performed.

    There are two main calendar types Activity Calendar and Resource Calendar.

    Activity Calendar

    Activity Calendar defines when work technically could be performed.

    • A low noise restriction
    • Production Freeze period 
    • SteerCo calendar

    Resource Calendar

    Resource calendar defines the availability of the assigned resource.

    Part-time specialist is available 9 am – 5 pm Monday – Wednesday.

      Work could be completed when both conditions are met.

      Let’s review a simple example with one activity and one resource only:

        If a two-day activity could only be performed on weekends (Saturday & Sunday) and the assigned resource only works Fridays & Saturdays, this activity only could be performed on Saturdays. The required effort is two days, activity duration is eight days (Saturday – Saturday).

          Not all scheduling tools can simulate scenarios with different activity and resource calendars correctly.

            Microsoft Project

            Microsoft Project correctly calculates the duration, start and finish dates (Saturday to Saturday). However, in the activity Gantt chart, it is unclear on which days the work is planned (only by Saturdays, not Sunday to Friday).

              Spider Project

              Spider Project correctly calculates duration, Start and Finish dates (Saturday to Saturday). Additionally, detailed scheduling in the activity Gannt chart shows exact dates (if needed, time as well) when the task is planned to be executed (Saturday + Saturday).

                Primavera

                Primavera also allows having activities and resource calendars. However, it is impossible to calculate the schedule with both calendars simultaneously.
                If the activity type is specified as “Task Dependent”, the schedule incorrectly shows that the activity could be performed on Sunday and Saturday:

                  If the Activity type is specified as “Resource Dependent”, the schedule incorrectly shows that the activity could be performed on Saturday and Friday.

                    Regardless of the Primavera setting, Duration, Start and Finish Dates will be incorrect.

                    In CA Clarity and Project on the Web also would not be able to simulate work for this mini-project correctly. These tools only support Resource Calendars, not activity calendars.

                    Apart from Activity and Resource Calendars project plan may require other calendar types:

                    • Project Calendar
                    • Team Calendar
                    • Shift Calendar
                    • Activity Lag Calendar

                     

                    Alex Lyaschenko

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

                    Monte Carlo Simulation challenges. Level of details challenge.

                    Monte Carlo Simulation challenges. Level of details challenge.

                    by | 7 Feb, 2023 | Blog

                    As discussed in the previous posts, applying the Monte Carlo Simulation (MCS) CORRECTLY for a large project may take many hours. As a workaround, some risk consultants recommend running simulations based on a high-level schedule, known as a control schedule and a ‘Level 3’ schedule.

                    The results of MCS performed based on the detailed schedule and high-level schedule are likely to be different, sometimes significantly different! There are a few reasons for that. In this post, we review one of them: the missing level of complexity.

                    Work packages are the smallest unit of work that a project can be broken down into when creating your Work Breakdown Structure.

                    In this post, the term ‘Work package’ (WP) represents ‘A group of activities’. It could be the smallest unit of work or a group of units.

                    When WP in a high-level schedule is represented by a single activity (or a few activities), the schedule misses a level of complexity of each WP. Without this information, the result of the simulation could be dramatically different.

                    Let’s review a simple example: A project has two WPs. Each of them has five 10-day activities, but in 1st WP all activities are consecutive, and in 2nd WP, all activities are concurrent.

                    If we decide to create a high-level schedule, we could simplify it to two linked ‘50 days’ and ‘10 days’ activities. The overall duration of both schedules and the logic between WPs will be the same.

                    Let’s assume each activity in our project has +/-2 days of uncertainty, which is +/-20%.

                    Detailed schedule with uncertainties:

                    High-Level schedule with uncertainties:

                    Now, we can calculate the probability of delivering this project in 60 days (the deterministic Most Likely scenario) and use both schedules as the base for the simulation. 

                    We are going to use a triangular distribution. As explained in the previous posts, the Beta / PERT distributions often better represent real-life probability, but they are unique to each risk analysis tool. I want to be sure that this experiment can be replicated with other risk analysis tools.

                    Also, due to the randomised nature of the Monte Carlo Simulation method, the result of any new simulation is always different. The more iterations performed, the less volatile results will be. I set the Spider Project to 50,000 iterations to minimise the volatility.

                    Project Probability Distribution

                    The performed simulation based on the High-Level schedule gives us the following probability distribution:

                    The performed simulation based on the Detail schedule gives us a different result:

                    There is 49.8% probability that this project could be completed in 60 days if the High-level schedule was used for this analysis and 29.2% probability if it was performed based on the Detail schedule.

                    However, project activities in both cases are going to be executed the same way, and the probability  should be the same. To understand such an anomaly, we need to go to the next level and analyse the probability of each WP separately.

                    1st WP probability distribution

                    The probability distribution of the first WP based on High-Level schedule:

                    The probability distribution of the first WP based on Detailed schedule:

                    Uncertainties in a sequence with ‘Finish-to-Start’ dependencies compensate for each other, so the result of the First WP simulation is roughly the same, regardless of the applied schedule. It is around 50%.

                    2nd WP probability distribution

                    As the second WP has only concurrent activities, the probability distribution curves are dramatically different.

                    Based on the Detailed schedule it is only ~3% chance that ALL activities could be completed in 10 days. If any activity is late (>10 days), the WP will be late.

                    In the High-level schedule, this level of complexity is lost, and the probability complete the WP in 10 days is 50%.

                    Probability distribution of the second WP based on the High-level schedule:  

                    Probability distribution of the second WP based on the Detailed schedule

                    There is a big difference between 3% and 50%! Depending on which result is presented to project decision-makers, it may lead to different actions.

                    Level of complexity

                    The analysed example above may look extraordinary. Not all projects have five linked concurrent activities. However, if we analyse any schedule, we are likely to find that there are days with more than five planned activities. All these activities are logically linked via direct or indirect logic. If these activities have large Total Floats, the effect of uncertainties should be immaterial. However, if they are on a project critical path or near a critical path, the effect will likely be noticeable.

                    Without Quantitative Risk Analysis (QRA), it may not be possible to understand the effect of uncertainties on project delivery dates.

                    Logic in real-life schedules is much more complex. WPs have other than ‘Finish-to-Start’ types of dependencies, technical and resource constraints, activity and resource calendars, lags and leads. These factors impact the level of complexity of each WP.

                    Also, logic between WPs is more complex than just a ‘Finish-to-Start’ dependency between the last activity in one WP and the first activity in another WP. On top of this, there could be more than one dependency between WPs, and these dependencies could be somewhere inside each WP, not between the end and start points:

                    Example of complex logic between WPs

                    The volatility of Critical Path

                    Another challenge is to demonstrate a Critical Path in a high-level schedule. A WP may or may not be on a critical path. If it is, it doesn’t mean that all activities in the WP are critical. The critical activities in the WP could be somewhere inside of WP. There also could be many critical fragments.

                    A scheduler may summarise critical and not critical activities in a high-level schedule. Unfortunately, there is no guarantee that the critical path is going to be stable during the life of the project. The volatility of the critical path means that a high-level schedule has to be constantly redeveloped.

                    Detailed Schedule

                    The described challenge is relevant to detailed schedules, not just to Control schedules.

                    There are no commonly accepted rules that define the correct level of detail for each schedule. While there are some recommendations, practically the level of detail depends on portfolio standards, the experience of the master schedule, the capacity of the scheduling team, applied schedule and risk analysis tools, and some other factors.

                    Two schedules developed for the same project by two different project teams are unlikely to be identical. The difference may look immaterial but may have a significant impact to the results of Monte Carlo Simulation.

                    Schedule duration paradox

                    The probability of delivering this project based on the ‘Most Likely’ durations is only 29%. This example demonstrates ‘Schedule duration paradox’:

                    Schedule based on the most likely activity durations doesn’t have the most likely duration

                    This is one of the factors why projects are late. When project SMEs provide the ‘Most Likely’ estimations for each schedule activity, and a scheduler uses them to develop a deterministic (Critical Path Method) schedule, project stakeholders often assume that such a schedule has ‘most likely’ delivery dates. Calculated dates are used as project commitments. However, due to the complexity of logic and parallel streams, the probability of meeting these commitments is likely to be less than 50%. Sometimes significantly less.

                    Monte Carlo Simulation is one of the Quantitative Risk Analysis (QRA) methods that help to calculate achievable dates, but it has to be applied correctly. A high-level schedule doesn’t have the same level of complexity as it is in a detailed schedule. It impacts the project probabilities calculated based on the Monte Carlo Simulation method. The difference could be sufficient to drive the project in the wrong direction.

                    There are many other important MCS challenges. I will continue “unwrapping” them one by one in my future posts.

                    Alex Lyaschenko

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

                    Risk Matrix: good or bad?

                    Risk Matrix: good or bad?

                    by | 22 Jan, 2023 | Blog

                    Some project risk practitioners argue that Project Risk Matrices cannot be trusted to produce consistent and correct risk ratings and rankings, and their application has to be minimised or even avoided.

                    However, often with the unique nature of projects, reliable risk rating and ranking are not possible regardless of applied methods and techniques.

                    Proposed alternatives may be able to address some issues associated with Risk Matrices, but not all of them and have other issues that Risk Matrices don’t have!

                    Arguing that the Risk Matrix technique is wrong would be similar to saying that a hammer is not a good tool because it may be inappropriately used instead of a screwdriver.

                    Risk Matrix is just one of the tools in a project management toolbox. There are situations when it is the most appropriate tool to use, situations when another risk management tool is preferable and situations when a Risk Matrix with another risk tool gives the best result.

                    It is essential to learn the weak points of this risk evaluation method, as some issues could be mitigated when applied smartly.

                    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