When you have multiple constraints, the most restrictive shall take precedence and drive your schedule but all Primavera software misses this. I agree with Paul Harris, although I do not have his book nor P6 I have also observed several misses with P3 and SureTrak and many times because of the complexity of the schedule could not figure where or why the unexpected results.

When I read the statement that P6 could not calculate float correctly when multiple calendars are used the obvious question was, what about when using multiple constraints? It was not difficult to find also erroneous results comes out of P3 and SureTrak, I was hoping P6 to be better.

If the activity scheduled with zero float constraint finish before the date constraint the zero float constraint shall drive the schedule, if the activity scheduled with the finish (early or late) constraint finish before the projected if scheduled with the zero float constraint then the finish constraint shall drive the schedule.

Still I do not get it why when he come across these issues he runs P3 and SureTrak as these are similar to P6, running Asta or other software that do not present these issues shall be enough.

With Spider Project I got the expected results, it can handle multiple constraints.

If the date constraint is latter than the zero float constraint we get.

With P3/SureTrak/P6 you should get the second scenario in apparent correctness and you wont see the issue but as the job progress the relative dates can invert and you might not notice, perhaps it will not make sense but if the job consists of hundreds of activities you will not figure easily why.

Now I wonder what would be the outcome if using Asta? To what league Asta belongs? Based on PH comments I expect it to be correct.

Mike,

Real life constraints do have their valid effect on schedules, the problem is when bogus software misses true impact because of their poor modeling. The same way constraints are needed for active schedule goes for modeled forensic analysis, here the problem again is the same but compounded by the protective attitude toward these software that those making the protocols have. Perhaps because some of their members have a vested interest in some of these software.

True impact shall consider the effect of all constraints, it is simple. If the software handling of constraints modeling is poor then some fix is in order, but the modeling by good software is better than the artificial fix. Why chemotherapy on a healthy patient?

It also applies to the identification of critical path, if your software can provide true Resource-Critical- Path and Resource Constrained Float it shall not be required to model Longest Path based on a computation that only solves the issue on multiple calendars but misses under resource leveling. Once again, why chemotherapy on a healthy patient?

Guess that because as Paul Harris says Primavera does not yields correct values of float under multiple calendar some protocols have gone so far as suggesting a method using a single calendar, which is wrong modeling but protects these software and still make reference to Primavera while miss mentioning the better handling of forensic models by Spider Project and other software that do not have such bug.

Shareef,

Thanks for your response, thanks for getting the bull by the horns.

Best regards,

Rafael