Tandyo,

You are correct, it is under certain conditions that checking the box for split in-progress task that what we woluld expect to work as retained logic behaves as progress override.

Seems like the issue with % complete is with the retained logic by checking the box for split in-progress task only and not with progress override by clearing the check box.

Got confused with the exception to the point I changed the statement on how to mimic progress override.

I am still wondering what the following statement from MS Project help, really means. "If this check box is cleared, remaining work is not split. The progress information is recorded on the originally scheduled dates, regardless of when the actuals took place."

I deal with MS Project up to the point where I import these jobs into Primavera SureTrak. Because of the prescence of MS Project eventually some day I will have to deal with progress updating in MS Project, good to know about it

Best regards,
Rafael

If this check box is cleared, remaining work is not split. The progress information is recorded on the originally scheduled dates, regardless of when the actuals took place.

Maybe you missed the warning of entering a % Complete as Paul Harris suggested in his posting (posting #3) under ttp://www.planningplanet.com/forum/forum_post.asp?fid=1&Cat=4&Top=63394

Quote from Paul Harris comment:

“When you check split in progress should work like Retained logic.”

“But when you enter an actual start without a % Complete it will work like Progress Override and then when you enter a % Complete of great than zero and less than 100 it works like Retained logic. This is not what one would expect, you just have to be careful.”

Therefore try the following and compare against unchecking Split in-progress:

In order to mimic Progress Override you must:
a) Check Split in-progress Task and,
b) Enter actual start without a % Complete.

In order to mimic Retained Logic you must:
a) Check Split in-progress Task and,
b) Enter actual start with a % Complete.

Anyway out-of-sequence logic is wrong and requires you to fix logic; this is what everyone should do whenever out-of-sequence happens no matter if you set Progress Override or Retained Logic. None is a guaranteed fix. You better avoid the error prone fix and make the required logic corrections; at times just a reduction in float will do it.

Try it by yourself, I am not an MS Project regular user, but as everyone I recognize it is the most widely used scheduling software in the world, eventually in some way you have to deal with it. Although not my favorite, contrary to the mainstream, I am glad it is good enough to be a true competitor to other more expensive software.

We got to accept plans are somewhat subjective in some way, it is good as is if feasible, and in this regard even a Gantt chart may be as good as or even better than a CPM in the wrong hands. Schedules are dynamic and that frequently things do not happen as planned, a correction for out-of-sequence means it did not happened as planned it does not means a faulty plan as many believe. Accepting the subjective nature of planning is something difficult for some forensic analysts, others have no problem with this as proof for cause and effect is not as strict as for criminal case. A good forensics analyst can prove cause and effect with reasonable precision under the knowledge and recognition there is always some subjectivity in planning.

Fix all out-of-sequence logic, there is nothing wrong with it, on the contrary not fixing out-of-sequence logic is wrong.

If/until Paul Harris come into our help I would recommend his book Planning and scheduling using Microsoft® Project 2007 including Microsoft ... By Paul Eastwood Harris. I do not have it but some sites provide you with a sample, seems quite good, a must have for those into MS Project.

Best regards,
Rafael

It works just fine for me, and has done for years.
Your expectation that MSP is P3/P6 is incorrect.

http://www.planningplanet.com/forum/forum_post.asp?fid=1&Cat=4&Top=63394