Why Constraints and other data?

Hanson,

When I say negative float is wrong is because time related computations using late values that are earlier than the system early values is the phisical equivalent of pseudomathematics, it is wrong modeling.

My argument is not that it is a better solution but that there is a correct solution but that the solution that uses physically impossible dates is wrong. A solution I do not claim to be mine as initially I was misguided and run over and over a physically impossible assumption until someone else told me.

In any case on the current schedule you shall not assign impossible dates, perhaps in a comparison schedule that did not happen. A comparisson I would call a "what if" but short of a current schedule.

Best regards,

Rafael

Hanson,

In the following figure you can see how SureTrak can handle the FNLT constraint without creating negative float, without artificially assigning impossible late dates and keeping correct float values. Please take note on the constraint finish type.

The concept is so simple it can be modeled in most CPM software easily.

The computations are not of my invention, Spider Project and perhaps other software perform these in similar way and I have seen forensic analysts suggest this method before.

Best regards,

Rafael

Gary,

You are missing the point, the discussion is about constraints and discussing faulty implementation of constraints goes to the bare bones of it.

It is also relevant the discussion of flawed computations constraint computations being required in US Jurisdictions, a major concern for those of us struggling to use better software than the required at gunpoint by some government agencies. The GSA might be the most notorious but it is not the only one that insist on brand specification.

... a different topic ???

Hanson,

In the following figure you will see how other software computes different Late Dates when FNLT constraints cannot be met. The output will not display the impossible, late dates being earlier than early dates and late S curves will never be on top of early S curves. FF will always be a portion of TF but never more.

I am not against the use of constraints, I am against wrong math.

Best regards,

Rafael

Rafael,

Please don't accuse me of wanting to "promote not knowing or even forbidding discussing the possibility of it being flawed."

Please just understand that I don't think it is fair on Hanson, or anyone who posts a question, to reply not answering the question asked, but instead discussing a different topic just because that is what you want to talk about.

That is called hijacking a discussion. Something which by replying here, I am also guilty of.

And in that vein, if you want to discuss this issue further, please post a new topic rather than replying to Hanson's

Gary,

If Primavera/ORACLE handling of constraints is considered flawed by others he should now, therefore this is a genuine advice specific to Primavera, even if you want to promote not knowing or even forbidding discussing the possibility of it being flawed.

If Primavera/ORACLE is flawed better he knows and understand why, and what other possibilities are there, and this include the knowledge of others believing it to be wrong. If Primavera/ORACLE is not flawed it shall be exposed in the debate anyway, in this way we all learn something, therefore we all win something.

That I believe Primavera/ORACLE computation of float under FNLT  (Finish No Latter Than) constraints is wrong does not means I do not believe that when these constraints cannot be met there is not criticality. In such case I believe there is criticality and it should be shown, my point is that historically someone started using wrong computations, no one ever dared to question it as if "taboo".

As you can see I dissent with Primavera/ORACLE computation of float under FNLT constraints as well as I dissent with those who want to surgically eliminate all use of constraints.

Common sense shall prevail, yesterday is not latter than today, FNLT constraints are real, shall not be forbidden when needed and criticality and float shall be correctly computed.

It is important to keep the discussion of the possibility of Primavera/ORACLE computation can be flawed, especially when you live in a jurisdiction like mine where it is common to force contractors to use what they believe flawed software against their will. This is not only wrong but illegal in our Government jobs procurement, it is a matter of public interest government agencies do not favor any specific service provider, still the GSA (General Service Administration) insist on such practice. As a matter of fact when it came out in the news a controversial GSA conference it was not to my surprise, but expected behavior.

http://www.lvrj.com/news/more-videos-revealed-of-controversial-gsa-conference-in-henderson-146731895.html

Hanson,

If you believe like I do, that negative float is wrong but that constraints are real modeling needs you can try the following.

• To any existing (old) intermediate FNLT constraint add another finish milestone (new) linked FS. Do not add any successor to the new milestone leaving it as an open end.
• Then add a no earlier than constraint to this new finish milestone with the date set equal to the FNLT constraint date on the old activity/milestine.
• Delete the old milestone FNLT constraint but leave the milestone.
• Set the software to calculate open ends as critical.
• Do not use project must finish constraint.

I do not have P6 but maybe in this way you can mimic Spider Project computations in a way it will show criticality without forcing late dates earlier than early dates.

I dissent with all CPM software whose calculations under FNLT constraints allow for the late dates being earlier than early dates, it is not about a single software. Although I understand we are after all a society with monkey ancestry I reject the idea of late being earlier than early.

You shall also investigate how your Late S Curves can be distorted as a result of distorted late dates being earlier than early dates. It is not uncommon that under high negative float jobs some will display at some point intersecting Early and Late S curves before project end, after the intersection then Late S curve will be above Early S curve adding to the confusion. Even if late curve do not reaches this extreme as for it to be on top of the early curve it will still be distorted.

Regarding your question about Risk Level, I understood it as the Probabilities of Success.

If you set up your deterministic schedule with a projected finish equal to contract finish date most probably you will miss the contract finish date. Even if there are few activities, all in tandem and you use average durations the probabilities of meeting the contract dare will be a mere 50%.

To make it easier to understand just imagine a single activity job, if using the average activity duration the probabilities of success will be 50%. Say the activity duration distribution is as follows; 10d, 20d, 30d and 40d , the average is 25 but you will make it only 50% if you plan for 25 days, still 50% of the time it will be 30d/40d. You got to target for early completion in the hope of making it.

Best regards,

Rafael

Rafael,

You may well be correct, but since this query was posted in the Primavera forum, I think it is safe to assume that Hanson is asking for advice specific to Primavera

The main problem is not with the use of constraints when needed, is on how some software enforce them when not attainable and thus create a wrong distortion of float calculation.

Beware not all software works the same way, not all enforce the impossible, like late being earlier than early. To show criticality and correct float values it is not necessary to distort float, use of correct mathematics can do it.

Best regards,

Rafael

1 - You should only use activity constraints if you absolutely need to -the vast majority of activities should not have any constraints and should instead be driven by their predecessors

2 - Unless your company tells you to enter this info, it is fine to leave it blank -it has no impact on the schedule

3 - Unless the client demands, leave this blank -if you enter a date here it will affect all of your float calculations

If you don't use 1 & 3, you will generally have a better schedule than if you do.