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.

Best regards,

Rafael

Gary,

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.

From http://www.mosaicprojects.com.au/PDF/Schedule_Calculations.pdf

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

Finish-No-Later-Than Constraints
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.

Best regards,

Rafael

Gary,

   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.       

Mike,

    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.
 

Best regards,
Rafael

 Rafael,

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.

Cheers,

G

free_float.jpg

Rafael,

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.

Yes, it can be +ve if you change the relation to FF.

I believe yes, it's can be TF +ve if you make the activities FF rather than FS.