Tracking logic changes can be a nightmare,
especially when it comes to large CPM networks with ever changing scope and
conditions. Many schedule specifications require that for each logic change, a
description for the basis of each change is provided and specifically
identifying the affected activities by Activity ID. In other words, the Owner
is not just interested in what changed, but more so, why the change was made.
Making matters worse, typically each change requires an individual explanation.
Comparison Report: Changed Logic To Existing Activities – shown below groups predecessor logic changes by Activity ID. The action taken, Added or Deleted Predecessor, is coded as AP or DP. The report also displays the Activity Name, Relationship, Lag and Total Float values. The advantage of this report is that all relationship changes including Predecessors and Successors whether deleted or added for any particular Activity ID is consolidate in one place.
Viewing only logic changes to existing activities removes all other Logic changes that were created as a result of adding or deleting activities between the Control and Modified Projects. This approach focuses attention to logic changes that were intentionally made to existing activities.
Tracking and identifying changes to the critical, longest
and driving paths is an important part of a Scheduler’s responsibilities. The
term “Driving Path” is the generic term P6 uses within its database to flag the
path that the User defines as either the Longest Path or Critical Path for the
Project.
In the Driving Path Activity Comparison report shown below. Line item activities 64 and 65 were on the Driving Path in the Control Project, however, they are no longer on the Driving Path in the Modified Project. Item #66 remains on the Driving Path for both Project Updates.
Items 68 thru 73 were added as part of the Modified Project, TS-BL3-UP29. As a result of being added during Update #29, these activities now fall on the Driving Path. The added activities also removed activity line items 64 and 65 from the Driving Path and increased their Total Float value from 0 to 24.
In addition, Item 77 is no longer on the Critical Path is the activity was actualized.
The report lists the Activity ID, Activity Name, Activity Type, the Control Project’s Driving Path Flag, Remaining Duration & Total Float, the Modified Project’s Driving Path Flag, Remaining Duration and Total Float. The Variance between Total Float value is the difference between The Modified Total Float and the Control Total Float values.
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.
The Filter option is probably the Scheduler’s most powerful
tool in P6. The Filter option allows the Scheduler to display only specific
activities based on the Filter criteria. There are a vast amount of options
that go beyond the scope of this article.
However, in this article, we will explore a not-well known or understood feature I’ll describe as “Multi-Leveling”. In other words, you can implement the multi-level filter technique that allows for multiple filter criteria to be combined into a single Filter.
In the sample Project shown below, “Thyme Street Bridge
Construction” consists of the construction 3 Piers comprised of Piles, Footers,
Columns and Caps. The Project is planned with 3 crews: a) a Pile Driving Crew;
B) a Footer Construction Crew; and C) a Carpenter Crew responsible for building
the Columns and Caps.
In this scenario, a reasonable CPM model for this Project would appear as shown below:
Now suppose we need to display
(or Filter) only the Cap construction for Piers 1 and Piers 3. Since the sample
set above is small, there are multiple options to accomplish this. However, for
the purposes of illustration, the most common solution would be to create 2
Filters. One filter to select only the Cap Construction, then another to select
Piers 1 and Piers 2. Once the 2 independent Filters are defined, the option to
“Show activities that match” is set to “All selected filters”.
The common solution approach
consists of:
Create a Filter to Select only Cap Construction as shown below:
The Filter shown above uses the “(All of the following)” option to select only activities containing the word “Cap”.
Create a Filter to Select Pier 1 or Pier 3 Construction as shown below:
The Filter shown above uses the “(Any of the following)” option to select only activities containing the word “Pier 1” or “Pier 3”.
Under the “Show activities that match” text, select the “All selected filters” option, then select both Filters created above as shown below:
The results of the 2 Filter selection criteria are correctly shown below:
The above solution is correct and operative, however, with the use of Multi-level Filtering, a better and more efficient solution can be constructed by combining both Filters into one Filter Criteria as shown below.
Create the first Filter criteria exactly as in Step 1 above as shown below:
Next, Include the next criteria similar to Step 2 above:
Add a third line using the “(Any of the following)” option similar to Step 2 above.
Add a fourth line, then enter the criteria “Where Activity Name contains Pier 1”. Make sure that Line 3 as shown below contains the “-“ symbol on the left indicating a second level is defined for the filter criteria. If the “-“ symbol is not shown, then click on the “Shift Right” arrow to create the second level. Notice also that the second “-“ symbol is indented indicating the second level criteria.
Add the fifth and final line, then enter the
criteria “Where Activity Name contains Pier 3”. Make sure line 5 begins with
“Or”. When done, select OK.
The results of the 1 Filter
selection criteria are correctly shown below:
This solution is more efficient since only 1 Filter used
eliminating the need to specify the “Show activities that match” option.
In conclusion, this simple example shows that the Filter option is more robust than what may initially appear. If necessary, additional levels can be added for more complicated Filters. The best way to improve your proficiency with Filters is to experiment with known results thereby better understanding its structure and behavior.
The Filters Module in P6 is a very powerful tool, and arguably regarded as a “Scheduler’s Best Friend”. However, when using – the “Activity Name equals/contains” option, incorrect results could arise when Activity Names contain embedded double spaces. An embedded double space is defined as double blank spaces contained anywhere within an Activity Name. Blank spaces at the beginning of the Activity Name is not considered since the P6 ‘contains’ or ‘Equals’ Filter option can trap this anomaly.
In the illustration below, there are 6 ‘Review Bids’ activities comprised of 4 Tasks and 2 Milestones. Of course, this small set could be a subset of a large CPM Network comprising of thousands of activities.
For this exercise, suppose the Scheduler is required to produce a report or layout identifying all the “Review Bids” activities for Bidding Review Team. The natural approach would be to create a filter as shown below:
Type: (All of the following)
Where Parameter: Activity Name
Is: contains
Value: Review Bids
However, when the Filter is activated, P6 returns the following results:
Unbeknownst to the Scheduler, only 4 out of the 6 activities appear. What happened? Activities EDS1020 and EDS1040 were excluded from the filter results.
Unfortunately, a common and
simple typographical error placed double blank spaces between the words “Review”
and “Bid”. Not only is this error easy to make, but is nearly impossible to detect
especially when you’re dealing with a CPM network consisting of thousands of
activities and where activity copy/pasting is used extensively.
In Zümmer Analysis Report: “[02] Activity Names with Embedded Double Space“, shown below, not only lists all instances, but the ‘Set Group’ column even shows you where to look. The report also tracks the Count Per Set and the Activity Count for each Set Group. Additional information on this report includes the Original Duration, Remaining Duration, and Total Float.
Since this is such an easy mistake to make, possibly resulting in erroneous reports, this issue must be checked and resolved by the Submitting or Reviewing Scheduler.
Using Zümmer concurrently with P6 helps identify and eliminate embedded double spaces.
Embedded Double Spaces can be resolved using the following Steps:
Open the CPM Network as shown below, with the P6 Filter set to “All Activities”.
2. Click on the first Activity Name cell so that the Select Marquee is shown around the Activity Name. If the Select Marquee is not highlighted around the Activity Name cell, the solution will not work.
3. Press “CTRL-R” to activate P6’s Replace Window as shown below:
4. In the “Find what:” textbox, enter 2 blank spaces. The 2 blank spaces will not show. The illustration above represents the 2 blank spaces with the gray rectangles.
5. In the “Replace with:” textbox, enter 1 blank space. The single blank space entry will cause the blinking cursor to shift 1 space to the right.
6. Finally, click “Replace All”. The “Replace All” option will scan through all Activity Names replacing every embedded double space with a single space.
7. If an Activity Name contains multiple embedded double spaces, the Find/Replace procedure will pause and redisplay the Replace window. Click “Replace All” to continue the process until all double spaces have been removed.
At the completion of the scanning process, all embedded double spaces have been replace by a single space as shown below. The highlight bar stops at the last replaced Activity Name.
How to Compare the Finish Profile between a baseline and update schedule.
A “Cash-flow S-Curve” is a very valuable tool that reveals much information about the characteristics of the scheduled Project. However, you may often come upon schedule updates that are not Cost or Expense loaded. You can still produce an “S-Type Curve” comparison by accumulating the Actual, Early, Late (and Mid) Finish Dates of the Tasks and Resource Dependent activities for both project updates.
Although this method may be a rough simulation of an actual Cost Load distribution, the resulting curves, in most cases can surprisingly provide a reasonable model of the Cash-flow as if the schedules were cost loaded. In the resulting curves, instead of defining the Y-Axis as Cumulative Cost, the Y-Axis is defined as the Cumulative Finish Date count.
Astute Zümmer user, Stephen Paterson, notes that these curves can be useful on types of projects where the client does not want it’s costs published out to all and sundry.
Zümmer’s Finish Comparison Profile Report (See illustration below) completes this task by:
1) Generating and Early, Late, Mid and Actual Finish Curves comparing between 2 Projects.
a. The Early Finish Curves distributes the Remaining Early Finish date of each Task or Resource Dependent activity between the Data Dates and the latest Finish dates in the 2 selected Projects. b. The Late Curves distributes the Remaining Late Finish dates of each Task or Resource Dependent activity between the Data Dates and the latest Finish dates in the 2 selected Projects. c. The Mid Finish Curves calculates the midpoint daily value between the distributed Early and Late Finish Dates. d. The Actual Finish Curves distributes the Actual Finish date of each Task or Resource Dependent between the Start of the Projects up to the Data Dates respectively.
2) Storing the graph and distribution data into a spreadsheet.
a. In addition to generating the Finish Comparison Profile report, Zümmer also generates an editable spreadsheet containing the actual chart appearing in the report along with the supporting daily and cumulative Early, Late, Mid and Actual Finish distribution calculations for the 2 selected Projects.
Finish Comparison Profile – Spreadsheet Output
When the Finish Comparison
Profile Curve is selected for previewing or printing, in addition to the
printed/previewable report, Zümmer generates a spreadsheet supplemental file
for the curve produced in the report.
The spreadsheet output file is stored in the Zummer/Output folder. In the illustration below, the Project TST-BL1-UP02 and TST-BL1-UP14 was selected for printing with the file listed. Note the file structure prefix consists of “FCP” then the next filename segment consists of the Project ID, “TST-BL1-UP14” (the selected Modified Project’s ID). The final filename segment is a 5-digit computer system generate suffix.
The “FCP” file in the “Chart1” Tab contains the “Finish Comparison Profile” Curves shown as below:
Since the file above is generated by a spreadsheet, the visual content
can be customized by the user and/or Cut/Copy & Pasted into another
document.
In the “FCP” file above, below is a partial section of the ChartData tab and the raw data used to plot the curve shown above: (Some Rows are hidden for instructional purposes).
Column A – “Profile
Date” contains the series of dates from the earliest date in the selected 2
Projects listing daily down to the latest date in the selected 2 Projects.
Columns B, C and D
contain the cumulative Early, Late and Mid Finish Date Count Series respectively
for the Control Project’s Finish Profile curve on the graph displayed in the
Chart1 tab.
Column E contains
the cumulative Actual Finish Date Series for the Control Project’s Finish
Profile curve on the graph displayed in the Chart1 tab.
Column F contains
the Total number of Tasks and Resource Dependent activities used to generate
the vertical Data Date line in the graph for the Control Project.
Columns G, H and I
contain the cumulative Early, Late and Mid Finish Date Count Series
respectively for the Modified Project’s Finish Profile curve on the graph
displayed in the Chart1 tab.
Column J contains
the cumulative Actual Finish Date Series for the Modified Project’s Finish
Profile curve on the graph displayed in the Chart1 tab.
Column K contains the Total number of Tasks and Resource Dependent activities used to generate the vertical Data Date line in the graph for the Modified Project.
Columns L, M, N and
O contain the daily Control Project’s total Early, Late, Mid and Actual Count
Series respectively used to calculate the cumulative values shown in Columns B,
C, D and E respectively.
Columns P, Q, R and S contain the daily Modified Project’s total Early, Late, Mid and Actual Count Series respectively used to calculate the cumulative values shown in Columns F, G, H and I respectively.
How to produce an “S-Curve” type graph when a schedule is not cost loaded.
A “Cash-flow S-Curve” is a very valuable tool that reveals much information about the characteristics of the scheduled Project. However, you may often come upon a schedule that is not Cost or Expense loaded. You can still produce an “S-Type Curve” by accumulating the Actual, Early, Late (and Mid) Finish Dates of the Tasks and Resource Dependent activities.
Although this method may be a rough simulation of an actual Cost Load distribution, the resulting curve, in most cases can surprisingly provide a reasonable model of the Cash-flow as if the schedule was cost loaded. In the resulting curve, instead of defining the Y-Axis as Cumulative Cost, the Y-Axis is defined as the Cumulative Finish Date count.
Astute Zümmer user, Stephen Paterson, notes that these curves can be useful on types of projects where the client does not want it’s costs published out to all and sundry.
Generating and Actual, Early, Late, and Mid Cumulative Finish Curves.
a. The Actual Finish Curve distributes the Actual Finish date of each completed Task or Resource Dependent between the Start of the Project up to the Data Date.
b. The Early Finish Curve distributes the Remaining Early Finish date of each Task or Resource Dependent activity between the Data Date and the latest Finish date in the Project.
c. The Late Curve distributes the Remaining Late Finish date of each Task or Resource Dependent activity between the Data Date and the latest Finish date in the Project.
d. The Mid Finish Curve calculates the midpoint daily value between the distributed Early and Late Finish Dates.
e. The height of the Vertical Data Date line is defined by the Total Count of Tasks & Resource Dependent activities in the Project.
f. The X Axis displays the Profile Date in which the range is bounded from the Earliest Project Start Date to the Latest Project Finish Date.
g. The Y Axis displays to Cumulative Finish Count which is bounded from 0 to the Total Count of Tasks and Resource Dependent activities. This means that Level of Effort, WBS Summary, and Milestone activities are not included in the graph.
h. The Total Task + Resource Dependent count is also displayed in the bottom of the report.
2. Storing the graph and distribution data into a spreadsheet.
a. In addition to generating a Finish Analysis Profile report, Zümmer also generates an editable spreadsheet containing the actual chart appearing in the report along with the supporting daily and cumulative Actual, Early, Late, and Mid Finish distribution calculations.
When the Finish Analysis Profile Curve is selected for previewing or printing, in addition to the printed/preview-able report, Zümmer generates a spreadsheet supplemental file for the curve produced in the report.
The spreadsheet output file is stored in the Zummer/Output folder. In the illustration below, the Project TST-BL1-UP02 was selected for printing with the file listed. Note the file structure prefix consists of “FAP” then the next filename segment consists of the Project ID, “TST-BL1-UP02”. The final filename segment, [97LLK], is a random computer system generated 5-digit suffix.
The “FAP” file in the “Chart1” Tab
contains the “Finish Analysis Profile” Curves shown as below:
Since the file above is a generated spreadsheet, the visual content can be customized by the user and/or Cut/Copy & Pasted into another document.
In the “FAP” file chart view above, shown below is a partial section of the ChartData tab and the raw data used to plot the curve shown above: (Note: Rows 3 thru 61 and 66 thru 404 are hidden for instructional purposes).
Column A – “Profile
Date” contains the series of dates from the earliest date in the selected
Project listing daily down to the latest date in the selected Project.
Columns B, C and D
contain the cumulative Early, Late and Mid Finish Date Count Series
respectively for the Finish Analysis Profile curve on the graph displayed in
the Chart1 tab.
Column E contains
the cumulative Actual Finish Date Series for the Finish Analysis Profile curve
on the graph displayed in the Chart1 tab.
Column F contains
the Total number of Tasks and Resource Dependent activities used to generate
the vertical Data Date line in the graph.
Columns G, H, I and J contain the daily total Early, Late, Mid and Actual Count Series respectively used to calculate the cumulative values shown in Columns B, C, D and E respectively.
Your Schedule Comparison Summary results are saved for future recall and variance analysis.
Whenever the Comparison – Include Summary option is checked, a 2-Page Summary Report is printed along with all the selected Comparison reports. In addition, the Summary Report containing the resulting totals of each individual numbered Comparison report is saved for later recall.
The Schedule Comparison Summary Module is accessible by clicking on the Toolbar Command Button Shown below:
Each individual Comparison
Summary is identified by a unique 6 digit “Series ID”. The prefix “SC” is used
to designate a series run for Schedule Comparison. The remaining 4 digits is a
unique name created from the system date and system time.
Every Schedule Comparison series run can be accessed from the Schedule Comparison Summary Module.
In the illustration above, a series run for Project ID MST-BL1 comparison to MST-BL1-UP01 designated ‘SCV802’ was created on 27-Jun-16 at 08:48. From the History Tab, the Schedule Comparison Summary Report can be reprinted containing the totals for each Comparison report printed for that Series.
Selecting the Excel Export option prints a spreadsheet format of the Series information. The Variance Tab allows any 2 Comparison series to be compared. The Item History Tab allows individual reports to be printed. The Item History Tab allows a more detailed trend analysis by grouping comparison line items across multiple Comparison Series runs.
Your Schedule Analysis Summary results are saved for future recall and variance analysis.
The Schedule Analysis Summary Module is useful in determining how analysis results are trending through the life of a Project. Whenever the Analysis – Include Summary option is checked, a 2-Page Summary Report is printed along with all the selected analysis reports. In addition, the Summary Report containing the resulting totals of each individual numbered analysis report is saved for later recall.
The Schedule Analysis Summary Module is accessible by clicking on the Toolbar Command Button Shown below:
Each individual Analysis Summary is identified by a unique 6 digit “Series ID”. The prefix “SA” is used to designate a series run for Schedule Analysis. The remaining 4 digits is a unique name created from the system date and system time. Every Schedule Analysis series run can be accessed from the Schedule Analysis Summary Module.
In the illustration above, a series run for Project ID: MST-BL1-UP06 designated ‘SAEII3’ was created on 27-Jun-16 at 09:31.
From the History Tab, the Schedule Summary Report can be reprinted containing the totals for each analysis report printed for that Series.
Selecting the Excel Export option prints a spreadsheet format of the Series information. The Variance Tab allows any 2 analysis series to be compared.
The Item History Tab allows individual reports to be printed. The Item History Tab allows a more detailed trend analysis by grouping analysis line items across multiple Analysis Series runs.
The Analysis Statistics Report is the next level of detail from the Analysis Charts. The second of 2 reports neatly display 4 key Project elements on 1 page. The Analysis Statistic Report is easy to produce and ideal for Schedule Manager reporting.
The illustration above is a sample output of a typical Analysis Statistics Report (2 of 2).
Duration Type: Details the Duration Type of every activity categorized by Activity Type.
Percent (%) Complete Type: Details the Criticality of every activity categorized by Activity Type.
Duration Threshold: Details all Non-Milestone activities and categorizes Activity Type.
Free Float activities count with distribution by Activity Type.
The Original Duration Threshold limits are User defined. The values are entered in the Criticality/Duration Assignment Module found under the Settings menu.
