When it comes to adding logic relationships in P6, things can get out-of-hand in no time. During the CPM network development phase, logic relationships are constantly added, deleted and revised. At the completion of the process the CPM network diagram can end up looking like a messy bowl of spaghetti.
Good scheduling practice calls for minimizing, as reasonably as possible, the amount of logic relationships in the CPM network. Cluttered CPM networks can add confusion, promote faulty logic and increase errors especially when trying to trace logic paths.
Before diving further into this topic, and for the purposes of this discussion, we must first define our terms and the difference between “Redundant Relationships” and “Duplicate Relationships”.
A Redundant Relationship is defined as: an additional logic relationship between 2 activities that are not directly related to each other.
In the example below, the FS relationship between Activity B (B) and Activity H (H) is redundant because an existing inferred relationship between these 2 activities already exists through B->C->D->E->F->G->H. Since B and F are not directly related, then the relationship B->F is said to be “Redundant” since intermediate activities exists between each activity which are along the same logic path.
Since the relationship B->H is redundant, then this relationship can be safely deleted and will not affect any dates or Total Float values of any activity within the CPM network. Redundant relationships are easily detectable when a logic path is neatly grouped so that activities of the same logic path are sorted by start date. In the example below, activities B thru G are group in the same logic path and are sorted by Start date. The 3 redundant relationships are clearly shown (B->H; C-> E; and E->G) by the dotted relationship lines and therefore can be safely deleted.
Even though a redundant relationship exists, it doesn’t necessarily mean that the relationship should be deleted. A Scheduler may decide to intentionally retain a redundant relationship in the CPM Network. For example, the redundant relationship may represent a secondary “fallback” relationship in case the current driving relationship is not sustainable.
For example, in the illustration above, suppose the current driving predecessor (D) to Activity E is no longer valid. Then, by removing the relationship, D->E, then the new driving predecessor to E will be C. If the redundant relationship, C->E had been previously removed, then when the relationship D->E is removed, E will revert back to the Data Date when the schedule is recalculated.
For this reason, using redundant relationship removal algorithms is generally not recommended. Furthermore, and unfortunately, when it comes to P6, all relationships (other than the relationship type) are the same. There is no direct way to differentiate “soft” relationships from “hard” relationships; or “primary” relationships from “secondary” relationships; or “physical” relationships from “crew” relationships.
Redundant relationship removal algorithms generally remove relationships regardless of their priority or classification. Therefore, the recommended method for removal of relationships is by individual consideration and inspection.
A Duplicate Relationship is defined as: an additional logic relationship between 2 activities that are directly related to each other.
Duplicate relationships can be classified into 2 types.
In the illustration above, the first type (Type 1) of Duplicate Relationship occurs when a SS/FF relationship pair is used. Typically, a lag value (typically greater than 0) is included in both relationship. This relationship technique is often used in summary level type schedules where the activity detail is not totally defined. Since the preferred technique in CPM networks is to allow only 1 relationship between any 2 activities, this usage is not recommended for detailed or production level schedules.
The second type (Type 2) of Duplicate Relationship occurs when the relationship pair is not of the SS/FF type. These duplicate pairs often occur when the “Link Relationship” option is inadvertently used a second time (or more) spanning activities that are already related. In most cases, the non-driving relationship is the relationship that should be deleted. Therefore, for K->L, the FF duplicate relationship can be safely deleted.
A subset of the Type 2 Duplicate Relationship is the “Multiple Instances” variety where more than 2 Duplicate Relationships exist between 2 activities. An example of this, as shown below, displays the relationships between M->N where every possible logic relationship exists between the 2 activities.
In the Successors relationship window above, since the Driving relationship is FS, then all other listed relationships can be safely deleted.
Zümmer’s Analysis Report #39 – “Duplicate Logic Relationships” shown below, lists all duplicate logic relationships in the selected Project.
This report groups duplicate logic relationships separated by a heavy horizontal line. In the example above, the duplicate logic relationship between M->N displays the Type 2 variety with all 4 assigned relationships. For this condition, the FF, SF and SS relationships can be safely deleted.
The next group, between K->L, displays the Type 2 variety with the FF/FS pair. For this condition, the FF relationship can be safely deleted.
The last group, between I->J, displays the Type 1 variety with the SS/FF pair. Here, the I->J relationship contains a lag of 5 days for both SS and FF relationships. If Activities I & J are part of a detail production level schedule, then breaking down the scope into more detailed activities may be necessary to eliminate the duplicate logic condition.
Copyright ©2020 FoxQuest Systems, Inc. – All Rights Reserved