How to detect and avoid those “stealthy” lag changes.
Maintaining a Project’s Completion Date is great but not by implementing what could be considered as concealing or under-handed measures.
In the illustration above, Test Project 1 – Update 01 with Data Date 17-May-20, highlighted Activity “C” is forecast to complete on 07-Jul-20. However, in the Test Project 1 – Update 02 with Data Date 17-Jun-20, Activity “C” has slipped by 14 calendar days to 21-Jul-20.
Miraculously:
the Project has maintained its Completion Date at 01-Sep-20 and;
The Finish date for Activity “D” remains at 28-Jul-20.
How did this happen?
There are many ways to manipulate a CPM network to mask lack of progress. One typical way involves introducing either a negative lag or reduced lag values especially along the critical path.
In the example above, The FF lag between Activity “C” and Activity “D” was reduced from 15 to 5 days, and a lag of -10 days was introduced into the FS relationship between Activity “C” and Activity “E”.
These subtle changes are difficult to detect since the graphical representation of the logic relationships are remarkably similar as shown in the illustration above. In a large CPM network, lag changes of this type can be easily missed.
Zümmer identifies these changes under Comparison Report #08 – “Logic Changes To Lag Only”. In the illustration below, Line Item #1 reports the FF lag change from 15 days to 5 days between Activity “C” and Activity “D” and; Line Item #2 reports the introduction of a FS negative lag of -10 days between Activity “C” and Activity “E”.
Since Lags are a property of Logic Relationships, a change in the Lag value is considered a change to the CPM logic and is reported as a logic change in other Zümmer comparison reports.
If you are receiving periodical CPM schedule updates and encounter these type of changes, it is especially important to report these issues back to the submitter so that further CPM logic changes of this type are prevented.
How to compare and report changes to the “Driving” Path
Comparing Driving Path Activities:
Determining and understanding how the Critical, Longest or Driving Path changes when comparing one update from another is an important part of a Scheduler’s responsibilities.
Regardless of how critical activities are defined in the Project Settings, internally in the P6 Project’s task database, the field name that flags critical activities is labeled as “driving_path_flag”. Therefore, for the purposes of this report and article the term “Driving Path” is used.
Some questions a Scheduler needs to answer:
What newly added activities are now on the Driving Path?
What activities are no longer on the Driving Path?
What Driving Path activities were completed?
What activities were deleted that were previously on the Driving Path?
The Zümmer Driving Path Activity Comparison provides this valuable information (and more) in a smartly designed and structured format.
In the Driving Path Activity Comparison Report:
The “Control” Project (as shown below) is defined as the Project Id that is being compared to. The Control Project is typically the Project update that has the earlier Data Date when compared to the “Modified” Project. In this case, the Data date is June 1, 2020.
The Modified Project (as shown below) is defined as the Project Id that is being compared against the Control Project. The Modified Project is typically the Project update that has later Data Date. In this case, the Data date is July 1, 2020.
In the detail band (as shown below), the Driving Paths from both the Control and Modified Projects are listed in an outer join format ordered by Activity ID. The list displays a line number count, the Control Project Status, Modified Project Status, Activity ID, Activity Name, Activity Type, Control Project Driving Path Activity flag, Control Project Remaining Duration, Control Project Total Float, Modified Project Driving Path Activity flag, Modified Project Remaining Duration, Modified Project Total Float and the Total Float variance.
Shown above, for Line Items #1 and #2: The activity status for each was changed from “Not Started” to “Completed”. Note that since these activities are completed, the Remaining Duration, Total Float and Total Float variance values are not applicable and therefore not displayed.
Shown above, for line item #3: This activity is on the Driving Path in both schedule updates. Note that the status changed from “not started” to “in progress” when Update 02 (the Modified Project) is compared to Update 01 (the Control Project).
Shown above, for line item #4 (as well as #6 thru #11 and #15): This activity is on the Driving Path in both schedule updates. Since the status remained unchanged as “Not Started”, it would be expected that the remaining duration would remain the same and the Total Float value would remain at 0.
Shown above, for line item #5 (as well as #12 and #14): This activity was on the Driving Path in schedule Update 01, however under Update 02, it is no longer on the Driving Path. The Total Float value for line item #5 changed from 0 to 2 days; or an increase variance of 2 days of Total Float.
Shown above, for line item #13: This activity was not on the Driving Path in schedule Update 01, however under Update 02, it is on the Driving Path. The Total Float value also changed from 4 to 0 days; or a decrease variance of 4 days of Total Float.
Shown above for line item #16: Since there is no status designation, Remaining Duration and no Total Float value for Update 01, this activity was added in Update #02 and inserted as a Driving Path activity.
In the page footer section shown below, a legend is for Activity Type and a legend for Activity Status is provided. In addition, the Run Date and Page numbering is provided.
Once printed, the Driving Path Activity Comparison Report can be directly inserted into a Submittal document with no further manipulation and provide documentation to support your review narrative. Additional similar Zümmer comparison reports include: “Added Driving Path Activities” and “Deleted Driving Path Activities”.
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.
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.
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.
Substantiate your monthly update narrative with these Zümmer Comparison Reports.
Most contract specifications
require the submittal of a narrative along with the standard Schedule Reports and
electronic file. Part of the narrative typically includes a section that
describes work accomplished during the previous reporting period.
Zümmer’s Comparison Reports:
1. [27] – Started Activities This Period; 2. [28] – Completed Activities This Period; 3. [31] – Actualization Report and; 4. [35] – Progress Data
…neatly provides documentation to develop and support the narrative.
In the illustration below, activities “D”, “E” and “F” started during the reporting period.
In the illustration below, activities “B”, “C” and “D” complete during the reporting period.
Zümmer’s Comparison Report [31] – combines started and completed activities. Since Activity “D” started and completed during the same update period, the Actualization Report contains only 5 entries.
Zümmer’s Comparison Report [35] – Progress Data – is used to identify those activities that have “Progressed” in the “Modified” Project when compared to the “Control” Project. In Zümmer, activities are said to have “Progressed” when any the following events occur:
1. An Actual Start is achieved; 2. An Actual Finish is achieved; 3. The Remaining duration of an ‘In Progress’ activity is reduced; 4. The Remaining duration of an ‘In Progress’ activity remains the same and the Percent Complete is increased.
It is important to note that
other sources, experts, or organizations may define “Progress” based on varying
criteria, however, in general, the above 4 conditions cover the vast share of
events.
The Progress Data report does not include activities that
are considered “non-progressive” revisions. In general, these
include:
1. Added or Deleted Activities; 2. Changes to Original Duration without a reduction to Remaining Duration; 3. Increases to Remaining Duration; 4. Unchanged Remaining Duration without an increase to Percent Complete.
This report is particularly
useful in documenting the Progress Only activities when creating or
investigating “Half Step” schedule updates.
The Progress Data report combines the following Zümmer comparison reports: [15] – In-Progress Tasks With Reduced Remaining Duration [31] – Actualization Report (except for added activities) [33] – Increased Percent Complete (where the Modified Remaining Duration is equaled to or greater than the Control Remaining Duration).
In the illustration below, activities shown are considered
“Progressed” because:
Line Item #1: Activity’s remaining duration decreased.
Line Item #2: Activity has completed.
Line Item #3: Activity has started.
Line Item #4: Activity’s remaining duration has remained the same, yet the % Complete has increased.
Total Float Consumption (TFC) generally
applies to Projects that have a fixed end date. For these Projects, consumption
of Total Float (TF) is a real commodity that should be monitored just as
zealously as the Critical Path. Most Project Specifications classify TF as a
“shared resource”.
However, if the TF of an early
activity is consumed, the TF values of its successor activities can be consumed
accordingly. This effect can result in placing a disproportionate burden upon
other later activities along a common TF path. In addition, TFC can also
increase the risk of completing the Project on time.
In the illustration below, the overall Project is completing “On Schedule”. However, activity “PR1150 – Roadway Design 90% – Prepare & Submit” is completing later when compared to the baseline schedule causing its TF value to decrease from 35 to 25 days.
This causes a cascading effect
where other activities along the same TF path have decreasing TF values as
well. For Example, activity “PR1100 – Area Roadway Construction” which happens
to be the last activity along the same TF path experiences an equal reduction
in TF value.
Zümmer’s Comparison Report, shown below, “Total Float Consumption” calculates the Gross TF between the Control and Modified selected Projects. In addition, the net Gained/Loss Gross TF is calculated along with the Gained/Loss TF Percentage.
“Behind the scenes” calendar changes can result in perplexing date changes (or lack thereof) between Project Updates.
Changing calendar settings is an easy (and sometimes underhanded) way to “block out” days in the calendar thereby changing schedule dates.
Zümmer’s Comparison Report #44 – Changed Calendar Settings – reports and detects these types of changes. It is possible for Global and/or Project Calendars to have the same Calendar Name yet have different calendar settings. Detecting this type of change is extremely difficult and time consuming using P6 alone.
The Change Calendar Settings report compares the 2 Project Calendar Settings and identifies any added and deleted Calendar assignments. In addition, the report lists the Calendar Name, Type of Calendar used (i.e. Project or Global), Hours per Day setting, and Count (# of activities using that Calendar).
Added Calendars have no Control Project ID Calendar Name match while deleted Calendars have no Modified Project Id Calendar match.
In the illustration below: Line Item #4 – A Global Calendar was assigned to 1 activity. Line Item #3 – The Calendar Name, Type and Hrs/Dy match exactly, however (indicated by the Asterisk) there was a change in the underlying Calendar Data set. In other words, for example, one or more days were changed from a Standard to Non-work day or visa-versa.
Changes to Calendar Data may also involve other settings. This report does not identify exactly what Calendar Data changed, however, knowing that there is a change is sufficient to warrant further investigation.
The Progress Data report is used
to identify those activities that have “Progressed” in the “Modified”
Project when compared to the “Control” Project. In Zümmer, activities
are said to have “Progressed” when any the following events occur:
1) An Actual Start is achieved; 2) An Actual Finish is achieved; 3) The Remaining duration of an ‘In Progress’ activity is reduced; 4) The Remaining duration of an ‘In Progress’ activity remains the same and the Percent Complete is increased.
It is important to note that other sources, experts, or
organizations may define “Progress” based on varying criteria, however, in
general, the above 4 conditions cover the vast share of events.
The Progress Data report does not include activities that
are considered “non-progressive” revisions. In general, these
include:
1) Added or Deleted Activities; 2) Changes to Original Duration without a reduction to Remaining Duration; 3) Increases to Remaining Durations; 4) Unchanged Remaining Duration without an increase to Percent Complete.
This report is particularly
useful in documenting the Progress Only activities when creating or
investigating “Half Step” schedule updates.
The Progress Data report combines the following Zümmer:
[15] In-Progress Tasks With Reduced Remaining Duration
[31] Actualization Report (except for added activities)
[33] Increased Percent Complete (where the Modified Remaining Duration is
equaled to or greater than the Control Remaining Duration).
In the illustration below, activities shown are considered
“Progressed” because:
Line Item #1: Activity’s remaining duration decreased.
Line Item #2: Activity has completed.
Line Item #3: Activity has started.
Line Item #4: Activity’s remaining duration has remained the same, yet the % Complete has increased.
