A simple question
Can an activity FF be a +ve value while the TF is -ve ??
knowing that the project (Must finish by) date is identified.
Ramy and Gary,
The question by Ramy was a logical question as he found some output by P6 that does not make any sense. But still other software like SureTrak misses CPM float and dates computations under multiple constraints. Just take a look at the following image you will see SureTrak is missing the FNL constraint while Spider does the correct math.
I would not be surprised if P6 also misses this condition. In any case using SureTrak to verify P6 math is not enough, you still need other software to verify SureTrak math.
Why do you think many cannot find the logic into their schedules? In part it is due to the wrong computations by bogus software that miss even the most basic logic, not in a single computation but in many.
Many thanks for your replies which have added new information to me.
Thanks again for your time & effort.
Can you please display again the image of your sample job? It is missing and when trying to figure out why the FF calculations in your software were wrong I got distracted by negative values of float that to me have no meaning as they distort traditional CPM.
The following image illustrates what I believe was the job you posted.
Please confirm my model if you cannot display your image again, pay attention to the constraints on each activity.
I believe your software missed the date constraint on the activity named Free Float. Look the following illustration where you will see how a FNL date constraint drive the EFT of the activity and this have an effect on the correct computation for FF.
Early Finish Time (EFT) The earliest point in time when the schedule activity can complete (based on preceding logic and constraints). Alternative name: Early Finish Date (EFD) or Early Finish (EF).
The early and late dates are both fixed at the constrained date. The constraint is placed on the finish of the activity and prevents the activity being scheduled later than the constraint date.
The constraint’s effect in time analysis is as follows:
- The Forward Pass on preceding activities is not affected.
- The Forward Pass EFT on the activity starts from the fixed date or from the analysed dates, whichever is earlier.
- The Backward pass on successor activities is not affected.
- The Backward pass LFT on the activity starts from the fixed date or from the analysed dates, whichever is earlier.
The computation as described above means that the error by P6 is due to the fact the calculation for EFT is missing the rule that says; The Forward Pass EFT on the activity starts from the fixed date or from the analysed dates, whichever is earlier.
Some PP users have warned about wrong calculations by P6, among them Paul Harris that go as far as recommending using other software to check P6 math. By default also dates as they are tightly related. If I were a P6 user I would follow Paul Harris advice and never trust on P6 calculations as you never know, it is not just under constraints that it fails, it is not just under resource leveling it fails but seems also under other conditions.
Please note that SureTrak misses considering all constraints in the FF calculation so I would not trust SureTrak even in the absence of negative float. Let say instead of constraining activity 2 with a FNL constraint you do it with an milestone activity that follows the end of this activity, the effect shall be equivalent. Therefore it is not just about the particular activity constraints but about all constraints that have an impact on it. As per pmbook reference [http://pmbook.ce.cmu.edu/10_fundamental_scheduling_procedures.html]; Constraints on finish times are included by identifying minimum finish times and then subtracting the activity duration. And here we need some backward computations. If your software does the right math it shall never yields FF values greater than TF in accordance to the postulates of the pmbook of reference.
Can you imagine the scenario where your successor has a contractual constraint but the software tell you the activity have FF that will break the contractual constraint? Well wrong calculations yield such results.
You are quite correct the the "project must finish by" constraint is actually a FNLT type, and not a mandatory finish constraint as I had previosuly said. I've corrected my previous posts to avoid any further confusion.
I think you are wrong about CPM definition of free float though. -I believe it is definied as the amount of time an activity can be delayed without affecting the Early Start of any of it's successors. I do not believe FF calculations do or should depend on late dates / backward pass calculations.
This is certainly how Primavera software treats FF, though I will understand if you choose not to take that as a ringing endorsement of my position ;o)
FNLT constraints (unlike mandatory constraints) affect only late dates and not early dates, hence distort the total float but not the free float values.
If I get a chance later, I will post another picture with the alternate constraint scenario you suggest.
Thanks a lot, you gave me exactly the example I was looking to remind me about such thing as negative float, you are of most value to PP.
We have 3 critical activities, one with positive FF value so it seems to me like the algorithm for FF is wrong as to my understanding all float calculations as per PMI shall take into consideration all constraints and all logic. Correct CPM algorithm for calculation of FF uses values from the backward pass, a pass that gets its correct and last activity values from the forward pass, when you break this link the FF computations get broken and you get results that makes no sense at all. It is insane to have some float calculation that depends on your constraints while other float calculations waive the link. Funny the link is broken for TF calculations but not for FF calculations.
We have late dates earlier than early dates which means activity can travel back in time, "Late" earlier than "Early", it just makes no sense. Negative float is a mockery of CPM calculations invented long ago by poor software developers that overlook the resource leveling issue.
I was expecting to see Late Dates and Early Dates equal when using mandatory constraints and still wonder if these constraints are Finish no Latter Than type. I understood project finish date constraint is of the FNL type and not of the mandatory type.
An activity is showing some positive FF value while it is critical with a negative total float value. Under Negative Float Criticality it should have no FF as it can be interpreted as the Oner can delay the activity with no consequences. I wonder how this calculations can be used under such contract scenario, is too confusing to be of real value other than providing some special dates and confusing the Contractor as to make it harder to issue valid claims. To me is like prostituting float calculations!
My software does not implement such thing as mandatory constraints and wonder what would happen to your example if you delete the project finish date constraint and substitute it with a finish milestone with a mandatory constraint.
I agree with you and perhaps the use of mandatory constraints to fix the milestones would be one of exceptions to those constraints, to keep a reference value that is a contractual requirement but without impacting the CPM logic.
Maybe CPM software should implement some special type of milestones/activities for "Contractual Milestones"/"Frozen Milestones" that can be frozen in time, that do not move with updates and that can only be linked to hammocks.
This is a very cogent and araldite discussion which goes to reinforce my philosphy that constraints should never be used in a construction programme.
You can set up a baseline mandatory completion date milestone and measure the difference between planned and actual.
the below has a "project must finish by" constraint of 31st Jan applied, which is what P3 calls a FNLT constraint. All links are FS(0) and there are no resources.
The effect of this constraint is to force the late finish of the final activity to equal 31st Jan, which generates a negative total float, using the calculation of Total Float = Late Finsh - Early Finish
The calculation for Free Float = Ealy Start (successor) - Early Finish (predecessor) is unaffected, as this constraint type only impacts on the late dates.
Hansi: I hope this explains why you do not need to change relationship to FF to "achieve" a +ve free float and -ve total float.
My software does not have functionality that breaks the rules of logic, therefore it does not implement mandatory constraints.
Still I am interested in looking at a sample job where the infamous mandatory constraints are the cause of free float larger than total float.
I would like to see an example where no resource leveling and no activity splitting is used or allowed as to see the effect isolated and perhaps have some fun with such a thing. I am just asking for a very simple job of 3 to 4 activities.
The key phrase there is "under any valid constraint conditions".
Since in the scenario presented to us there is a FNLT constraint which is causing the negative total float, it is clear we are not operating under valid constrain conditions.
In layman's terms, free float is the number of working days an activity can be delayed without delaying any of it's directly-succeeding activities. This calculation will not change regardless of what date, if any, is selected as the project finish constraint.
Hence you can have a positive value free float and a negative value total float, so long as you are happy to distort your total float calculations by using constraints.
In all cases, total float equals or exceeds free float, while independent float is always less than or equal to free float.
A mathematical relationship that shall hold for continuous PDM under any valid constraint conditions.
Therefore if TF is a negative value then FF cannot be of positive value, it must be of a negative value equal or less than TF.
If your software give different results it is faulty, under resource leveling I have seen weird calculations by substandard software. Under resource leveling negative float calculations make no sense and can yield wrong values.
At the moment I do not have the reference, but recall some time ago I read that for years some non-continuous PDM software based on AOA (Activity on Arrow) were using wrong algorithms for free float. It also might be that automatic activity splitting by some software can yield unsuspecting results as they split an activity in two and compute values using "two activities" instead of one.
Some software even allows you to define float in different ways, there are options for; Compute Total Float as:
1- Late start-Early start
2- Late finish-Early finish
This adds to the confussion and allows for Float to be whatever you want it to be !
Yes, it can be +ve if you change the relation to FF.
Yes activity FF can be +ve while TF is -ve.
The type of relationship is irrelevant.
FF does not care about FNLT constraints, but TF does.
I believe yes, it's can be TF +ve if you make the activities FF rather than FS.