Interruptible and contigous logic

Ali,
What do you mean by contiguous and interruptible logic? Both P3 and P6 use same logic methods and have option to retained logic, progress overide or actual dates and options to calculate critical path. It is depends on the planner to have open end on his choice but not a good practice.

Hi Ali

I am really looking forward to Rafael’s response to this one.

Best regards

Mike Testro

Hi Ali,

(while waiting for Rafael)...Yes, I believe that’s valid.

In P3, "interruptible" extends the task bar (when using FF) from the data date, while in P6, there’s no option for interruptible.

But why you don’t want to use FF relationship?

Best regards

Anoon,
P6 has also has option for interruptible based on expected finish date which is equivalent for P3 interruptible (finish constrain but can start separately).

Hi Rodel,

I’m not sure, but I’d used "expected finish date" as well, and I believe it’s not the same or equivalent to "interruptible" as the schedules (P6 vs. P3) behaves differently (when using FF).

Best regards

Hi Anoon,
My apology, you’re correct. Expected finish date extend the bar and duration while interruptible extend only the bar but not the duration.

Ali,

I do not know if P6 only uses contiguous logic, perhaps it calls it as activity splitting.

I do not believe in automatic activity splitting, the scheduler should specify how each split is going to be done, also the software should show each split as a separate activity with its own float, and especially resources as when you split an activity most probably there will be inefficiencies must be considered.

The following reference, although I do not agree with regard to automating activity splitting, can be of interest.

http://www.pmicos.org/topics/aug2006tom.pdf

Activity splitting recognizes available free float to the left of an activity, a useful metric no software developer has ever provided. Then it splits the activity on a limited set of rules that again should not be the same for all activities, it shall be on a one by one basis.

Continuous activity shall be the norm, not activity splitting. FF relationships, a very dangerous sharp knife with which once in a while you cut yourself must be avoided as much as possible and if needed beware of the traps, yes Mike you are right is kind of dangerous.

Some people argue all software should allow for activity splitting on per activity case but avoid mentioning about the splitting rule, it shall also be on a per activity so better split the activity yourself and get all the activity information not available if summarized on a single activity line.

With Mikes approach I do not believe this issue exists as he decides when and how to split the activity. I am 95% with him but leave 5% for the rare occasions "non FS" (SS/SF/FF) represent true logic and even can allow for situations where by increasing the duration of an activity some successors finish date(s) is(are) reduced.

Ali I believe you are right, if you are not using FF relationships activity splitting will never happen. If you are not using FF relationships because you have no need for it then you can set the activity splitting option on and use whatever splitting rule you wish, perhaps an impossible to occur rule so splitting will never happen even in the presence of FF relationship.

Best regards,
Rafael

Hi Rodel,

No worries, yes in P6 it extends both bar and duration, but I supposed that is, if you use "expected finish constraint (with FF relationship)", while if not, (using only the schedule options), P6 schedule will behave as if using the "contiguous" option in P3.

Best regards

In contiguous logic, the FF relation will drive the succ, and the start date will be calculated backward...in other words, the start date of the activity will be determined as finish - duration with no respect to the pred.
Interr vs. Contig. only affects FF relation, by avoiding this type, there will be no diff b/w cont. and inter. logics.
Expected finish cannot be used because dates might change when updating -> expected finish usually distorts the logic.
I agree with Rafael, it is better to split the activity if necessary.

Thanx everyon

Ali,

Under Contiguous logic if the activity has SS and FF predecessors both logic constraints will be respected as well as the requirement for the activity to be continuous. It might be that the activity is driven by a FF link until you increase its duration enough for the SS links become driving.

Under Contiguous logic either one SS or FF link is driving while duration is contiguous. Under non contiguous logic, the release of the requirement for the activity to be contiguous allows for the first split be driven by the SS links while the last split is driven by the FF links. If you increase the activity duration there will be a point activity will become contiguous and the SS link will become the driver.

The problem is that the splitting rule, if this is what you want to model, shall not be the same for all occasions, automatic splitting shall be considered non good practice, contrary to what some are requiring or advocating, including some members of the PMI and a few surviving advocates of the Activity on Arrow network representation which initially adopted the non contiguous calculation of early dates.

Best regards,
Rafael