Redundant Logic Identification – (Plus a free demo tool for identifying redundant relationships in P6 schedules)

Logic is one of the key characteristics of a schedule. A proper analysis on the logic is a must due to the fact that the quality and integrity of a schedule can be significantly impacted by the logic. Validating all logic on future tasks for correctness and correcting any out-of-sequence logic are some sample checks that schedulers deal with when it comes to logic analysis. One of the challenges that schedulers encounter in terms of logic check is identifying redundant logic and unnecessary links between activities.

As stated in scheduling best practices and guidelines (e.g., The GAO Schedule Assessment Guide and US Air Force IMS Assessment Process) logic redundancy increases the complexity of project schedules; makes schedules harder to understand and can have a negative impact on the analysis performed on project schedules (e.g., analyzing the logic network and schedule risk analysis). Thus, it is really important to be able to identify redundant links and remove them from schedules effectively. Obviously, removing redundant logic would not result in a change to task dates.

Concept

To get an idea regarding the concept of redundant logic, let’s have a look at Fig.1 . In this example, there is a Finish to Start (FS) link from Task A to Task B (Task B is the successor of Task A). There is also a FS link from Task B to Task C, which means Task C is the successor of Task B. Now, a FS link from Task A to Task C (shown below in blue) is considered redundant since Task A and Task C are already linked to each other through Task B. In other words, Task C is the successor of the successor of Task A, which implies that Task C is already the successor of Task A.

Fig.1- Example #1- Sample logic with redundancy

The sample logic, depicted in Fig.1 is more or less the logic used in the literature to explain the redundant logic concept. However, generally speaking, if Task C is the successor of Task B and Task B is the successor of Task A, it does not necessarily mean that a link from Task A to Task C is redundant. For instance, in Fig.2, there is a Start to Start (SS) link between Task A and Task B (i.e., Task B is the successor of Task A) and a FS link between Task B and Task C (i.e., Task C is the successor of Task B). In this case the FS link between Task A and Task C is not redundant.

Fig.2- Example #2- Sample logic without redundancy

A comparison between Fig.1 and Fig. 2 can help us to understand another important factor in determining redundant links: In Fig.1, Task B is driving Task C (i.e., the free float between Task B and Task C is less than the Free float between Task A and Task C), however, in Fig.2 it’s Task A that drives Task C (i.e., the free float between Task A and Task C is less than the Free float between Task B and Task C). Fig.3 and Fig.4 show the predecessors of Task C for Example #1 and #2, and the driving ones identified by the scheduling software.

Fig.3- Predecessors of Task C in Example #1; Task B is driving

Fig.4- Predecessors of Task C in Example #2; Task A is driving

Redundant Logic Identification

To identify potential redundant links/relationships, one should:

A)   identify the successors of each task in the schedule, and figure out the number of paths that start from the task and end in each successor. If there is more than one path from the task to its successor, there might be a potential logic redundancy. For example, in Fig.1, Task A has 2 successors; Task B and Task C. As per activity network shown in Fig.5, there is one path from Task A to Task B, but there are two paths from Task A to Task C (i.e., Path #1: A-C: FS and Path #2: A-B: FS →B-C: FS). This means there might be a potential redundancy between Task A and Task C.

Fig.5- activity network depicting Task A and its successors

 Let’s have a look at another example: in Fig.6 Task A has one successor, i.e., Task B. As shown in the activity network diagram, there are 2 paths from Task A to Task B. (i.e., Path #1: A-B: SS and Path #2: A-B: FS). This indicates there might be a potential redundancy between Task A and Task B.

Fig.6- activity network depicting Task A and its successor Task B

In real world projects, identifying the number of paths that start from a task and end in each of its successors can be quite complicated and utilizing computers are sometimes inevitable.

One algorithm that can be used to identify redundant relationships is illustrated in Table.1. To clarify the algorithm further, a sample project is shown in Fig.7 and the algorithm will be applied to this sample project. In this table the first column indicates the tasks we see in Fig.7.

Fig.7- Example#3- A sample Activity network diagram

Table.1- Tasks, Successors and “successors of the successors” for the sample project shown in Fig.7

There is a block in the table that represents the successors of each task. For example, Task A has 3 successors : B, B and D (i.e., A-B: SS; A-B: FS and A-D: FS). There is another block in the table that represents the “successor(s) of the successor(s)” of each task. Every cell in this block is either a successor of an immediate successor of a task or a successor of the previously identified successors in the “successor(s) of the successor(s)”. As shown in Table.1, for Task A, the “successor(s) of the successor(s)” would be C, E and D (i.e., B-C: FS, D-E: FS and C-D: FS). In this case, Task C and Task E are the successors of the immediate successors of Task A (Task C is the successor of Task B and Task E is the successor of Task D), and Task E is also the successor of both Task C.

Once the table is generated, the “Successor” block should be checked and if there are any duplicates in that block for a task, the duplicate is a potential redundancy. For instance, for Task A, Task B is repeated twice and is for that reason there is potential redundant relationship(s) between Task A and Task B.

 Furthermore, if a successor in the “Successors” block is also available in the “successor(s) of the successor(s)” block, that identifies a potential redundancy between the successor and its predecessor shown in the “Task” column. For example, in Table.1, for Task A, Task D in the “Successors” block is also available in the “successor(s) of the successor(s)” block. This means the relationship between Task A and Task D is a potential redundant relationship.

For Task C in Table.1, as shown Task E is under both the “Successors” block as well as the “successor(s) of the successor(s)” block, which means there is a potential relationship redundancy between Task C and Task E.

 B)   check the relationship between the task and its successor for the links identified as potential redundancy in the previous step. If the relationship is driving, that relationship is no longer considered as redundant. Otherwise, it would stay as a potential redundant relationship/link. For instance, in Fig.5 it was identified that there might be a redundant relationship between Task A and Task C. Referring to Fig.3, it can be seen that FS relationship between Task A and Task C is not driving. So that relationship stays on the list of potential redundant relationships. Looking at Fig.6, the FS relationship between Task A and its successor (i.e., Task B) is driving, however, since the SS relationship between Task A and Task B is not driving, we can consider this SS relationship as a potential redundancy.

Some scheduling software including Primavera P6 might incorrectly identify a relationship as driving when start and/or finish dates of the predecessor or the successor in that relationship are actualized.

C)    Check and ensure removing a potential redundant link/relationship does not result in missing logic, open start and/or open finish situations.

Missing logic or open ends refers to activities that are missing a predecessor, a successor or both. Each activity should have at least one predecessor and one successor linked to it. Ideally, each schedule is supposed to contain just 2 open ends, i.e., project start and finish milestones.

An open start, refers to an activity that has only finish-to-finish (FF) or start-to-finish (SF) relationship(s) with its predecessor(s). Start milestones can have FS or SS predecessors. Finish milestones can have FF predecessors.

 An open finish, refers to an activity that has only SF or SS relationship(s) with its successor(s). Start milestones can have SS successors. Finish milestones can have FS or FF successors.

This check is really important in terms of finalizing the list of redundant links. Let’s have a look at Fig.6: as stated before, the SS relationship between Task A and Task B is a potential redundancy. By removing the SS relationship between Task A and Task B, Task A still has a successor, Task B still has a predecessor so there wouldn’t be any open ends. Task B wouldn’t have an open start since there is a FS relationship between Task B and its predecessor (i.e., Task A). Task A wouldn’t have an open finish since there is a FS relationship between Task A and its successor (i.e., Task B).

D)   Review the list of redundant relationships carefully (preferably with the help of project team and subject matter experts) before removing the identified redundant relationships from schedules. An identified redundant relationship might be initially created for a purpose. One should be very knowledgeable about why it was originally inserted before deleting it. Also, ensure the identified redundant relationships will not become the driving relationships in the future. A relationship might appear to be redundant before the project start, however, this does not necessarily mean that it will not become driving as the project progresses in ways that were not initially planned. 

Computer Implementation

In order to identify potential redundant logic in schedules created in Primavera, I developed a VB .Net application. This “Redundant Logic Identifier” (RLI) application takes care of the first 3 steps mentioned above in the “Redundant Logic Identification” section. In other words, this application identifies potential redundant links in schedules, however, the 4th step (i.e., step D) which is reviewing the identified redundant links should be taken care of by subject matter experts.

Utilizing the RLI application requires the following steps:

1-    Getting an export from Primavera P6 in Excel format

2-    Importing the excel file into the RLI application. The application takes care of identifying the potential redundant relationships and updating the excel file.

3-    Reviewing the results identified in the excel file

4-    Importing the excel file back into Primavera P6

A demo version of the developed RLI application can be found in the comments section below.

This demo version is free and can analyze schedules that contain no more than 50 activities. This app works best on the schedules that are not actualized yet (for instance schedules that are yet to be approved as baseline). Actual dates can impact the results and some actualized relationships that are redundant might not be identified as redundant links.

Please feel free to download, use and share.

To utilize this app the following steps should be taken:

Step 1- Getting an export from Primavera P6

In P6, go to file and then select “Export”.

 Select “Spreadsheet- (XLS)” or “Spreadsheet- (XLSX)” depending on the version of P6 and click “Next”.

Select “Activities” and “Activity Relationships” and click “Next”.

Click on “Add” and assign a name (e.g., “RedundantLogicExport” to the template.

With regards to “Subject Area”, pick “activities” and ensure “Activity ID”, “Activity Status”, “WBS Code”, “Activity Type” and “At completion Duration” are selected respectively. 

Now, change “Subject Area”, to “Activity Relationships” and ensure “Predecessor”, “Successor”, “Relationship Type”, “Predecessor Activity Status”, “Successor Activity Status”, “Predecessor Activity Name”, “Successor Activity Name”, “Lag”, “Activity Relationship Count”, “Driving”, “Predecessor Free Float”, “Successor Free Float”, “Predecessor Start”, “Predecessor Finish”, “Successor Start” and “Successor Finish” are selected respectively. 

Click “Ok” and save the Excel file at your desired destination.

The exported Excel file should look similar to the below snapshots with regards to Tabs and columns.

Step 2- Importing the excel file into the RLI application. 

Click on “Browse” and select the Excel file you just exported from P6.

The application will analyze the relationships and updates the excel file.

Step 3- Reviewing the results identified in the excel file

the “TASKPRED” tab in the updated excel file will be updated and potential redundant relationships will be shown.

Subject matter experts should review the list and in case a potential redundant relationship should not be removed the “d” under column “Q” should be deleted for that specific relationship. Now the file is ready to be imported to P6.

Step 4- Importing the excel file back into Primavera P6

In P6, go to file and then select “import”.

 Select “Spreadsheet- (XLS)” or “Spreadsheet- (XLSX)” depending on the version of P6 and click “Next”

Then select the updated excel file and then select “Activity Relationships” and click “Next”.

Select “Update existing Project” under “Import Action” and select the project under “Import to” and click “Next” and then click on “Finish”.

This will remove redundant logic from your schedule.

#PrimaveraP6