Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Interruptible and contigous logic

11 replies [Last post]
Ali Farhat
User offline. Last seen 14 years 6 weeks ago. Offline
Joined: 23 Oct 2008
Posts: 120
Groups: None
As far as I know, unlike P3, P6 only uses contiguous logic...my only answer for the consultants request to use interruptible logic is :"I WILL NOT USE FF relationships". Does P6 actually use the interruptible logic and how, and if not, is my answer valid?

Regards all planners,

Replies

Muhammad Rahman Z...
User offline. Last seen 13 years 4 days ago. Offline
Joined: 15 Aug 2011
Posts: 2
Groups: None

Helloo,,

I have one confusion regarding changing the logic....

if Successor activity starts prior to start of predecessor activity then to avoid out of sequence report, either we have to change logic from FS to SS or it is allowed to change relationship from defined predecessor to another new predeccor. And if it is allowed then we have to also take care of close loop to calculate find Total Float.

 

Regards

MRZ

Rafael Davila
User offline. Last seen 2 hours 31 min ago. Offline
Joined: 1 Mar 2004
Posts: 5233
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
Ali Farhat
User offline. Last seen 14 years 6 weeks ago. Offline
Joined: 23 Oct 2008
Posts: 120
Groups: None
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
Anoon Iimos
User offline. Last seen 2 years 31 weeks ago. Offline
Joined: 22 Sep 2006
Posts: 1422
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

Rafael Davila
User offline. Last seen 2 hours 31 min ago. Offline
Joined: 1 Mar 2004
Posts: 5233
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
Rodel Marasigan
User offline. Last seen 11 weeks 3 days ago. Offline
Joined: 25 Oct 2006
Posts: 1699
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.
Anoon Iimos
User offline. Last seen 2 years 31 weeks ago. Offline
Joined: 22 Sep 2006
Posts: 1422
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
Rodel Marasigan
User offline. Last seen 11 weeks 3 days ago. Offline
Joined: 25 Oct 2006
Posts: 1699
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).
Anoon Iimos
User offline. Last seen 2 years 31 weeks ago. Offline
Joined: 22 Sep 2006
Posts: 1422
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
Mike Testro
User offline. Last seen 22 weeks 1 day ago. Offline
Joined: 14 Dec 2005
Posts: 4418
Hi Ali

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

Best regards

Mike Testro
Rodel Marasigan
User offline. Last seen 11 weeks 3 days ago. Offline
Joined: 25 Oct 2006
Posts: 1699
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.