The Official Site for Zümmer – CPM Schedule Analysis & Comparison – Copyright ©2012-2023 FoxQuest Systems, Inc.

The Finish-to-Finish Relationship Trap

Think twice before using Finish-to-Finish relationships between tasks.

By definition, a Finish to finish (FF) relationship is:

A relationship in which the finish of a successor activity depends on the finish of its predecessor activity.

Unfortunately, as will be explained in the article, FF relationships can cause illogical and erroneous results in your CPM network without any warnings or error message. Too often FF relationships, especially when no lag is used between tasks, as shown in Figure 1, are used without consideration of the negative effects this may impose on a CPM network. Even seasoned Schedulers with decades of scheduling experience can easily fall into this trap considering this relationship as acceptable and reasonable and will fervently defend its use with a multitude of “real-world” examples.

To understand the issue, we must first remove any “real-world” justification from the argument by realizing that P6 does not care about your Activity Name. The forward & backward pass algorithm works exactly the same regardless of what Activity Name is typed in. Therefore, we must approach this issue from an abstract perspective. Any use of a “real-world” example will almost always cause anyone to justify its use and therefore perpetuate its mis-use.

The FF Trap – Issue 1 – What is the true successor?

Figure 1 – FF relationship between tasks.

In the Figure 1 above, the successor to Activity A is Activity B. P6 allows this relationships and this counts as a non-opened end. However, upon further inspection, assigning the finish of Activity B as a successor leaves much to be desired. What’s missing is understanding how the CPM network progresses. One should ask “What task continues along this path?” Assuming Activity B is the only successor to Activity A, then Activity A is missing a successor that is tied to its start. This falls in the “No Finish Side Successor” logic error category.

Zümmer Analysis Report # [14] – “Activities with No Finish Side Successor” (shown below in Figure 2) identifies each Activity that violates this anomaly.

The FF Trap – Issue 2 – What is the true predecessor?

In the Figure 1 above, the predecessor to Activity B is Activity A. P6 allows this relationships and this counts as a non-opened end. However, upon further inspection, assigning the finish of Activity B as a predecessor leaves much to be desired. What’s missing is understanding how Activity B is progressed by the CPM. One should ask “What task allows Activity B to start?” Assuming Activity A is the only predecessor to Activity B, then Activity B is missing a predecessor that is tied to the start of the Activity B. This falls in the “No Start Side Predecessor” logic error category.

Zümmer Analysis Report # [15] – “Activities with No Start Side Predecessor” (shown below in Figure 3) identifies each Activity that violates this anomaly.

The FF Trap – Issue 3 – Which activity has priority over controlling the start of the Activity 2?

Figure 4 – Which Activity controls the start of Activity 2?

In Figure 4 above, the predecessor to Activity 2 is Activity B with a Finish-to-Start (FS) relationship and the predecessor to Activity B is Activity A with a FF relationship. However, upon further consideration, you may ask if there is no lag between Activity A and Activity B, then which activity actually controls the start date of Activity 2? Without a lag between Activity A and Activity B, then both Activity A and Activity B equally control the start of Activity 2. In conclusion, in this case, the predecessors to Activity 2 is both Activity A and Activity B with a FS relationship. Therefore, the correct network logic to use is shown in Figure 5 below.

Figure 5 – Correcting the FF between task anomaly.

Zümmer Analysis Report # [35] – “Tasks with Finish-to-Finish Relationships and No Lag” (shown below in Figure 6) identifies each Activity that violates this anomaly.

The FF Trap – Issue 4 – Potential erroneous Early Start/Early Finish dates for Activity B.

In Figure 1 above, the FF usage may appear reasonable when considering Activity A and Activity B alone. However, considering other activities in the CPM network, the calculated Early Start, Early Finish date and consequently the Total Float values may be incorrect for Activity B. Even worse, P6 does not provide any warning messages, notice or explanation of this potential error.

Figure 7 – Incorrect Early Start for Activity B

In the Figure 7 above, note that the Original Duration for Activity A is greater than Activity B. In the case, when the CPM network is calculated, the Early Start for Activity B is no longer controlled by the Early Finish of Activity 1. The FF relationship shown is essentially pulls the start of Activity B away from its normal driving predecessor and behaves as if Activity B was assigned an “As Late As Possible” constraint. In other words, the driving predecessor to Activity B is defined by the finish of Activity A and the Early Start is defined the Early Finish of Activity B minus the Original Duration for Activity B.

Figure 8 – Incorrect Early Start for Activity B when Activity A OD is < Activity B OD.

In Figure 8 above, the same situation occurs when total when Activity B is less that Activity A, but the Original Durations between Activity 1 and Activity 3 is greater than Activity B. Again, P6 provides no error message or notice for this issue.

Figure 9 – A possible solution to resolve FF between Activities A and B.

The immediate solution to this issue may be to revise the logic (as shown in Figure 9 above) so that Activity B starts after Activity 1. However, this might not be the intent of the Scheduler to accurately model the start date for Activity B. For example, if the Original Duration for Activity A is much greater than Activity B, then the CPM network model in Figure 9 may not correctly convey the Schedule’s intent.

Figure 10 – Alternative Solution to Resolve FF between Activities A and B.

When the Original Duration for Activity A is much larger than Activity B an alternative solution is to break Activity A into 2 activities. In Figure 10 above, Activity A2 is added to the CPM network with an Original Duration with about the same Orginal Duration as Activity A1. The sum of the Original Durations of new Activities A1 and A2 is the same as the Original Duration of Activity A in Figure 9.

The FF Trap – Issue 5 – What about lags?

Figure 11 – FF with a lag between tasks.

The use of a lags in a CPM network is probably a discussion all to its own. However, with regard to FF relationships with a lag, special care should be considered prior to its usage. When a FF lag is inserted, as shown in Figure 11 above, the CPM network, at least declares that Activity B has priority over the start date of Activity 2. This solves the problem discussed in

Issue 3 above. However, even though a lag is inserted between Activity A and Activity B, this does not necessarily resolve the problems associated with Issue 4 above.

The FF Trap – Issue 6 – FF lag greater than Successor’s Original Duration

Figure 12 – FF lag greater than Successor’s OD.

In Figure 12 above, a FF lag is inserted between Activity A and Activity B. Unfortunately, the FF value is greater than the Original Duration (the successor) for Activity B. This usage causes an “non-overlapping” relationship condition. Issue 6, is one of four possible non-overlapping conditions.

Sadly, this relationship error is very easy to commit. For example, suppose Activity A and Activity B was originally added to the CPM network with Original Duration of 10 and the FF lag is set to 5. Here, the lag value of 5 is small enough so that both Activity A and Activity B overlap. This is an acceptable condition. However, suppose now that the Original Duration for Activity B is reduced to 4 Days. More often than not, these type of schedule changes are made without consideration of a lag value that was previously inserted. Now, with an Original Duration of 4 Days for Activity B, the FF lag of 5 Days results in a non-overlapping condition of 1 day.

Zümmer Analysis Report # [35] – “Finish-to-Finish Relationships & Lag Greater Than Successor’s Original Duration” (shown below in Figure 13) identifies each Activity that violates this anomaly.

Figure 13 – Zümmer Analysis Report [34].

The FF Trap – Issue 7 – When is it appropriate or best to use a FF relationship?

Figure 14 – Predecessor task -> Successor Finish Milestone.

After reading through the perils of FF usage, you may ask when is it appropriate or best to use FF in a CPM network? Fortunately, an excellent way to use FF relationships is when the successor activity type is a Finish Milestone (as shown in Figure 14 above). Since a Finish Milestone does not have a start component, using FF relationships here is an excellent choice. Although P6 does allow the use of FS between the finish of a task and a Finish Milestones, using a FF relationship keeps your relationship lines neat and tidy. Figure 15 below, the left panel shows the effects of using mixed relationship type when the successor is a Finish Milestones. In this case, it is much preferred is to consistently use a FF relationship. The right panel in Figure 15 below, illustrates the neat and tidy results when FF is used.

Figure 15 – Keeping relationship lines neat & tidy.

The FF Trap – Summary

P6 is a versatile and powerful CPM networking tool, allowing 4 different relationship types (FS, FF, Start-to-Start (SS) and Start-to-Finish(SF)) with the ability to assign a lag value (including negative lag values). However, much care and consideration should be used when using any one of these relationship types, especially anything other than the typical Finish-to-Start relationship is used. The bottom line, here is to build a CPM network with very limited use anything other than the tried-and-true FS relationship. All other relationship types, should be used only in deliberate and clearly justifiable situations.

Finally, the converse to the FF Trap is the equally perilous SS Trap which is discussed in detail in “The Start-to-Start relationship Trap” article.

An in-depth look at the Activity History Module

A powerful tool to plot activity history and perform trending analysis

Activity History Module Basics

The Activity History Module Toolbar button highlighted above

The Activity History Module is a powerful yet simple tool that allows you to track the status of any activity across multiple Project Schedules. There are a few prerequisites that must be set for the Activity History Module to work properly.

Zümmer assumes that the Project Schedules used in the Activity History analysis are in at least one, but not more than ten Enterprise Project Structure (EPS) nodes. Project Schedules that are assigned as baselines do not appear within the EPS and therefore, are not selectable for this analysis. If you have a baseline assigned Project Schedule and you want to use it for Activity History analysis, then restore that Project Schedule and place it in one of the selected EPS nodes.

Start with a well designed EPS layout

A well design Enterprise Project Structure (EPS) is very helpful in perform Activity History analysis.

In the illustration above, a typical EPS is displayed. Note that the EPS nodes are displayed in Dark Blue, Green and Yellow while the Project Schedules are listed below in White with black font. Also, note that some EPS nodes do not have Project Schedules immediately under then while others do. For example, EPS node “TST4” does not have any Project Schedules while EPS Nodes “TST4-Current” and “TST4-Baseline” has 1 Project Schedule each and “TST4-Updates” has 6 Project Schedules.

The next step is to identify the Project Schedules to be used in the Activity History analysis. Typically, this involves using multiple Project Schedules updates for the same Construction Project. In the illustration above the Thyme Street Towers 4 Project has 1 Baseline schedule and 7 monthly updates.

In Zümmer, the next step is to define the EPS Nodes that will contain the Projects that will be used for the Activity History Analysis. As illustrated below, from the Main Menu, select Settings-> History Tracking.

Once selected, the History Settings displays as shown below. The Available Nodes listbox on the left alphabetically displays all EPS Node that contain at least 1 Project Update or Baseline. The Selected Nodes listbox on the right displays the Selected EPS node to be included in the Activity History analysis. In the illustration below, EPS Nodes “TST4-Current”, “TST4-Updates”, and “TST4-Baseline” have been selected. A maximum of 10 EPS Nodes can be selected for the Activity History analysis. Click OK when the all the EPS Nodes have been selected.

When the OK button is clicked, Zümmer saves the Selected Nodes for Analysis History Graphing, Trending and Reporting. In addition to the Selected Nodes, all Projects under the selected nodes will be used for the Analysis History analysis. Therefore, In the example above, Projects: TST-BL4-UP07, TST-BL4-UP06, TST-BL4-UP05, TST-BL4-UP04, TST-BL4-UP03, TST-BL4-UP02, TST-BL4-UP01, and TST-BL1, and all the activities within these Projects will be considered in the Activity History Module analysis.

The Activity History List

Once the EPS nodes are selected using the Settings->History Tracking option, the Activity History Module is ready for use.

When the Activity History Module Toolbar button is clicked, the Activity History Graphing window is displayed as shown below.

Within the Activity History Graphing window, the “Activity List” and “View Graph” Tabs are displayed along with the Activity ID Textbox and Search Button, the Activity ID and Activity Name grid, “Show a Linear Trendline and Forecast Completion” checkbox.

In the illustration above, the listed Activity ID’s and Activity Names are displayed as a result of the EPS Nodes selected from the Activity History Settings option. The entire list of Activity ID’s and corresponding Activity Names originate from the Projects contained in the EPS Nodes selected. The Activities are sorted by Activity ID. You can select any Activity by scrolling down or you can enter an Activity ID (or beginning part) into the Search Textbox.

In the illustration above, note that Activity ID “MS30250” is listed twice. The Activity List here will display multiples instances of the same Activity ID when differences in Activity Name for the same Activity ID appear within the selected Project Updates or baselines. In the example above, two Activity Names for Activity ID “MS30250” occur in the Project Updates/Baseline under the selected EPS nodes.

Any Activity ID, Activity Name can be selected by scrolling up or down the listbox or by entering a valid or beginning part of the Activity ID (or beginning part) into the Search Textbox and click on the Search command button.

As illustrated below, the specific Activity ID/Activity Name is highlighted when selected.

When the “Show a Linear Trendline and Forecast Completion” checkbox is selected, a “Trendline” graph will be produced, otherwise a standard graph is produced.

To produce a history graph of another Activity ID, simply return to the Activity List Tab, select another Activity ID, and then return to the View Graph Tab.

Activity History – View Graph

When an Activity ID and Activity Name is selected in the Activity List Tab and the View Graph Tab is clicked on, the Activity History Module processes the selected Activity ID and automatically displays the Activity History Graph for viewing. Since the graphing selection and printing process queries through many activities, expect the loading process to take a few moments before displaying.

As illustrated below, the example is shown below. The graph header and Tab page headers display the selected Activity ID and Activity Name. In the graph presentation, the X Axis represents the range of Data Dates for the selected Activity. The Y Axis on the left represents the range of Early Finish Dates for the selected Activity and the green curve plots the Early Finish Dates. The red horizontal line plots the baseline date (or the date from the earliest Data Date schedule). The Y Axis on the right represents the Total Float value for the selected Activity and the brown curve plots the Total Float values.

Positive slope Finish Date graphs generally indicate an activity that is slipping or reporting a later finish date as the Activity is reported through Project Updates.

Zero slope Finish Date graphs generally indicate an activity that is maintaining the finish date as the Activity is reported through the Project Updates.

Negative Finish Date slope graphs generally indicate an activity that is accelerating or reporting an earlier finish date as the Activity is reported through the Project Updates.

Negative slope Total Float graphs generally indicate an activity that is slipping or reporting a reduced Total Float values date as the Activity is reported through Project Updates.

Zero slope Total Float graphs generally indicate an activity that is maintaining the Total Float value as the Activity is reported through the Project Updates.

Positive slope Total Float slope graphs generally indicate an activity that is accelerating or reporting an increased Total Float value as the Activity is reported through the Project Updates.

A green colored segment on the Finish Date graph indicates that the finish date is not complete for the Data Date point on the X-Axis. The Finish Date graph is a shaded area to emphasize the finish dates.

Assuming that the CPM network logic and Original Duration remain the same through the updates, increasing Finish Dates results in reduced Total Float values and decreasing Finish Dates results in increasted Total Float values.

The Preview Report command button previews a tabular report version of the graphical display. The Print command button previews the graphical display in a report format for printing later.

Activity History Graph – Print

When the Print button is selected, the Activity History Graph print report format is displayed as shown below.

This option allows for final preview and verification prior to final printing. Clicking on the Print icon from the Print Preview menu prints the Activity History Graph in reportable format as shown below.

If the selected activity contains finish date from the selected schedule updates, the finish date curve is shown in blue as shown below:

Activity History Trendline Chart

For Projects, where activities are slipping from update to update, you may ask yourself where this project or a specific activity is heading.

Although trending is merely a calculated projection, Zümmer’s Activity History module does allow you to show a linear trendline and to forecast a date based on the trendline.

In the illustration above, Activity: “MS32500 – Boiler Room – Install Boiler”, the finish date has been slipping at variable rate over the previous eight updates. The current update with Data Date projects a completion date of September 1, 2020.

To display the Activity History Chart to include a Trendline, from the Activity List Tab, first select the Activity ID, then check the checkbox “Show a Linear Trendline and Forecast Completion” as shown below:

When the View Graph tab is selected, based on the trend over the past 8 updates, the Forecast Finish Date is shown below as September 28, 2020.

The Forecast trendline date is determined by finding the date along the trendline where the Data Date (X-Axis) is the same as the Finish Date (Y-Axis). Finding the date along the trendline can be determined by calculating the Slope and Y-intercept from the selection of Finish Date and the Data Date. See Paragraph – Activity History Trend Spreadsheet Output for more details on how the Forecast Finish Date is calculated.

In addition to generating the Activity History Graph and Trendline below, Zümmer also generates an editable spreadsheet containing the actual graph appearing in the report along with the supporting data points.

Activity History Tabular Report

The Activity History Module is an immensely powerful yet simple tool that allows you to track the status of any activity across multiple Project Schedules.

The Activity History Graphs – Activity List Tab, lists all the activities that exist across all the Projects under the selected EPS node(s) defined in the Activity History Settings.

Next, click on the View Graph Tab. An Activity History Graph is displayed. (Click on the Print button to display and print the graph).

The Preview Report button generates a tabular version of the graphical data points along with:

Activity Status, Activity Description, Project ID, Data Date, Start and Finish Dates, Total Float and Days To Complete (See illustration above).

The “Days to Complete” value is the # of days between the Data Date and the Finish Date.

Activity History Graph Spreadsheet Output

When the Activity History Graph Curve is selected for previewing or printing, in addition to the printed/previewable report, Zümmer generates a spreadsheet supplemental file for the curves produced in the report.

The spreadsheet output file is stored in the Zummer/Output folder. In the illustration below, Activity MS03240 – Boiler Room – Install Boiler was selected for printing. Note the file structure prefix consists of “AHG_” then the Activity ID segment consisting of the Activity ID, “MS03240”. The final filename segment is a 5-digit computer system generate suffix.

The “’AHG” file in the “Chart1” Tab contains the “Activity History Curve” 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 “AHG” file, shown below, displays the ChartData tab and the raw data used to plot the curve shown above.

Column A contains the series of Data Dates appearing on the X-Axis of the Graph from the earliest Data Date to the latest Data Date selected for the graphing analysis.

Column B contains series of Finish Dates for the selected activity appearing on the left Y-Axis and the shaded area of the Graph for each of the Data Dates on the X-Axis.

Column C contains series of Finish Dates for the selected activity appearing on the left Y-Axis and the green/blue line Graph for each of the Data Dates on the X-Axis.

Column D contains series of Total Float values for the selected activity appearing on the right Y-Axis and the brown line Graph for each of the Data Dates on the X-Axis.

Column E contains the series of Baseline date for the selected activity appearing on the left Y-Axis and the red horizontal line. The Baseline date is the date found in the Finish Date in cell B2 for the first Data Date in cell A2.

Column G contains series of Actual Finish Dates for the selected activity appearing on the left Y-Axis and the blue line Graph for each of the Data Dates on the X-Axis.

Columns F and H through J contain information to create Trendline data to include, Trend End Date, Actual Finish, Trend Intersection, Intercept and Slope. See Paragraph – Activity History Trend Spreadsheet Output for more information.

Cell K2 contains the Activity ID and Cell L2 contains the Activity Name.

Activity History Trend Spreadsheet Output

When the Activity History Trend Curve is selected for previewing or printing, in addition to the printed/preview report, Zümmer generates a spreadsheet supplemental file for the curves produced in the report.

The spreadsheet output file is stored in the Zummer/Output folder. In the illustration below, Activity MS32500 – Boiler Room – Install Boiler was selected for printing. Note the file structure prefix consists of “AHT_” then the Activity ID segment consisting of the Activity ID, “MS32500”. The final filename segment is a 5-digit computer system generate suffix.

The “’AHT” file in the “Chart1” Tab contains the “Activity History Curve” 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 “AHT” file, shown below, displays the ChartData tab and the raw data used to plot the line graphs shown above.

Column A contains the series of Data Dates appearing on the X-Axis of the Graph from the earliest Data Date to the latest Data Date selected for the graphing analysis. The last Data Date value is the Trend End Date that is calculated based on the Trend Intersection calculated in Cell H4, the Intercept value calculated in Cell I4 and the Slope value calculated in Cell K4. The values in the last Data Date row and Column F combine to display the the Trend End Date shown on the graph.

Column B contains series of Finish Dates for the selected activity appearing on the left Y-Axis and the shaded area of the Graph for each of the Data Dates on the X-Axis.

Column C contains series of Finish Dates for the selected activity appearing on the left Y-Axis and the green/blue line Graph for each of the Data Dates on the X-Axis.

Column D contains series of Total Float values for the selected activity appearing on the right Y-Axis and the brown line Graph for each of the Data Dates on the X-Axis.

Column F contains the Trend End Date that is calculated based on the Trend Intersection calculated in Cell H4, the Intercept value calculated in Cell I4 and the Slope value calculated in Cell K4.

Column G contains series of Actual Finish Dates for the selected activity appearing on the left Y-Axis and the blue line Graph for each of the Data Dates on the X-Axis.

The Trend End Date is calculated in Cell K4 using the equation “=ROUND(I4/(1-J4),0)”. Where the equation for a line, Y=mX+b is used. The Trend End Date is defined as the date when the Y and X values along the Trendline is the same. Since Y=X in this case, the Trend End Date value is: (b/(1-m)).

Summary

As detailed above, the Activity History Module is indeed a powerful tool that allows the user to present activity history progress and trends in a professional and clear manner. Further modifications and enhancements are available by accessing the graphs and data from the spreadsheet created.

New release of CPM Schedule Analysis & Comparison with Zümmer Manual – 9th Edition

Zümmer has been a proven and successful tool for analyzing and comparing CPM schedule for over 10 years now.

Since it’s release in 2012, Zümmer has never set still. Improvements to the applications features and reporting tools has been a continuing effort. Thanks in part to many suggestions received over the year by its faithful users. It is our goal to continue to improved on its features and functionality as long as CPM schedule continues to be the industry standard in construction scheduling.

We understand that deciding on a suitable analysis & comparison tool can be a complicated decision for any organization and especially for larger organization with extensive IT rules and guidelines. Therefore, our team is dedicated to making your decision as streamline as possible.

Zümmer has be tested and evaluated by some of the largest organizations in the construction industry and has passed Risk Assessment such as Crowdstrike Threat assessment testing with flying colors.

In addition, to make your decision making process easier, you can now download the entire Zümmer Manual (all 479 Pages, 45MB) here.

Some new Zümmer features include:

Improved Activity History reporting and graphing:

Activity History Graphing now includes Baseline and Total Float values

The Activity History module now displays the Total Float value and baseline date for each Data Date update selected.

Additional Change Logic Reporting:

4 new Change Logic reports have been added to monitor and report logic changes that are related directly to Driving Path activities and to changed Original Durations.

Track Logic changes to Driving Path Activities and Changed Original Duration

Added Item History Settings capabilities:

You can now better manage your Item History reporting by using the Item History Settings window shown above.

The Zümmer development team is dedicated to providing you with the tool you need to maintain the highest standards in your CPM schedules and in your CPM schedule deliverables. Even if you decide not to use Zümmer, the manual can help you understand nuanced topics regarding CPM scheduling and help you become a better scheduler.

Detecting and Reporting Logic Changes to Lag Only

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.

Comparing Driving Path Activities

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”.

The Zümmer Predecessor Successor Report

Print a smarter and more efficient Predecessor Successor Report

Print a clear and concise Predecessor Successor Report from Zümmer

A CPM Schedule “Predecessor Successor Report” is a standard and valuable tool for documenting and examining an activity’s predecessor and successor relationships. However, creating this type of report in P6 is not only time consuming and difficult, but the resulting output is typically tough to read and cryptic. Even worse, this type of report, which is typically lengthy to begin with, is even more lengthy when using the formats available in P6’s reporting tools.

Zümmer’s version of the Predecessor Successor Report is not only concise and well organized but also contains more pertinent information than most other Predecessor Successor Reports found in many “How To” articles found online.

Page Header – Project ID Information

The Page header shown above displays the Project ID, Project Name and Data Date for the selected Project.

Group Header – Activity Information

Each Group is sorted alphabetically by Activity ID. The Group header band starts with a light red shaded area and displays the Activity Status, Activity ID, Activity Name, Activity Type and Total Float value. The Total Float is not shown for activities that are completed.

Each Activity ID in the Group Header band is prefixed by “*”. This allows for quick searching within a PDF or other electronic type file. For Example, in the sample above, to find the Predecessors and Successors for Activity “MPBR3590”, type “*MPBR3590” in the search window. This will find the Group Header Activity ID instead of the same Activity ID that might exist in the Predecessor/Successor detail band.

Detail Band – Predecessors and Successors

Directly below the Group Header Band is the Predecessor/Successor detail band. This detail band is sorted first by Predecessor shown in a blue font then by Successors shown in a red font. Within each Predecessor/Successor band, the activities are listed alphabetically by Activity ID and displays the Relationship type (“P” for Predecessor and “S” for Successor), Activity Status, Activity ID, Activity Name, Activity Type, Total Float value, Relationship Type and Lag value.

Page Footer – Legend Information

The Page footer displays a Legend for the Activity Type, a Legend for the Activity Status, the Run Date (date printed) and the Page numbering.

Report Total – Project Logic Count

On the final page, a total count of all the logic relationships is displayed.

Once printed, the Predecessor Successor Report can be directly inserted into a Submittal document with no further manipulation.

Keeping Resource Cost and Schedule in Sync

Use these 4 Zümmer Analysis Reports to keep your Resource Cost and schedule in sync.

Keeping Resource Costs and schedule status in-sync can be a nightmare even in a moderately sized CPM Network. In this type of environment, it is possible to have an independent Cost Engineer and Schedule Engineer responsible for developing and maintaining Resource Costs and schedule making this effort even more complicated.

In an ideal situation, Resource Costs and schedule status are In-Sync when:

1) an activity has not started, and the Actual Resource Cost (Expenditures) is equaled to 0;

2) an activity is in-progress, and the Resource Cost Actual Cost To-Date is be between 0 and the Budgeted Cost;

3) an activity is complete, and the remaining Resource Cost is 0.

Obviously, the ideal situation is rarely the case and, in some instances, can even be justified. Regardless, when schedule and Resource Cost status get Out-of-Sync, these instances should be identified, reviewed, and adjusted accordingly.

There are 4 Out-of-Sync possibilities: (See illustration below)

1) Resource Cost exist on activities that have not started.

2) There is Remaining Resource Cost on activities that are complete.

3) There is no Remaining Resource Cost on activities that are in-progress.

4) There is no Actual Resource Cost on activities that are in-progress.

Zümmer checks for Possibility #1 with Analysis Report – “Expenditures on Not Started Tasks” illustrated below.

Zümmer checks for Possibility #2 with Analysis Report – “Remaining Cost On Completed Tasks” illustrated below.

Zümmer checks for Possibility #3 with Analysis Report – “No Cost to Complete on Tasks in Progress” illustrated below.

Zümmer checks for Possibility #4 with Analysis Report – “No Cost To Date on Tasks in Progress” illustrated below.

Each report lists the Activity ID, Activity Name, and either Budgeted Cost, Cost to Complete, or Expended Cost value. Line Items are highlighted when an unbalanced condition occurs. Unbalanced conditions occur when the Budgeted Cost is not equaled to the Actual Cost plus the Remaining Resource Cost value.

Keeping Expenses and Schedule in Sync

Use these 4 Zümmer Analysis Reports to keep your expenses and schedule in sync.

Keeping expenses and schedule status in-sync can be a nightmare even in moderate sized CPM Networks. In this type of environments, it’s possible to have an independent Cost Engineer and Schedule Engineer responsible for developing and maintaining expenses and schedule making this effort even more complicated.

In an ideal situation, expenses and schedule status are In-Sync when:

1) An activity has not started, and the Expense Actual Cost to-date is 0;

2) An activity is in-progress, and the Expense Actual Cost To-Date is be between 0 and the Budgeted Cost

3) An activity is complete, and the Expense Remaining Cost is 0.

Obviously, the ideal situation is rare and in some instances, can even be justified. Regardless, when schedule and expense status get Out-of-Sync, these instances should be identified, reviewed and adjusted accordingly.

There are 4 Out-of-Sync possibilities: (See illustration below)

1) Expense Actual Costs exist on activities that have not started.

2) There is Expense Remaining Cost on activities that are complete.

3) There is no Expense Remaining Cost on activities that are in-progress.

4) There is no Expense Actual Cost on activities that are in-progress.

Zümmer checks for Possibility #1 with Analysis Report #48 – “Actual Expenses On Not Started Tasks” illustrated below.

Zümmer checks for Possibility #2 with Analysis Report #49 – “Remaining Expenses On Completed Tasks” illustrated below.

Zümmer checks for Possibility #3 with Analysis Report #50 – “No Remaining Expenses on Tasks in Progress” illustrated below.

Zümmer checks for Possibility #4 with Analysis Report #51 – “No Actual Expenses on Tasks in Progress” illustrated below.

Each report lists the Activity ID, Activity Name, Budgeted Expense, Actual Expense and Remaining Expense value. Line Items are highlighted when an unbalanced condition occurs. Unbalanced conditions occur when the Budgeted Expense is not equaled to the Actual Expense plus the Remaining expense value.

How to Guarantee Delivery of a Global Calendar Free P6 Export File

Nearly every P6 Export File I have ever received has a Global Calendar embedded in it.

Many construction project specifications state that Global Calendars and Global Activity Codes (Global Activity Codes will be discussed in a separate article) are not to be included in the Project Schedule. The reason is that the Owner or Agency wants to control the number of Global Calendars in their P6 CPM Network.

Imagine a large agency such as a State Department of Transportation that receives Project schedules from scores of Contractors. If the Global Calendars are not properly managed, the agency can easily wind up with literally hundreds of Global Calendars. Many of these Global Calendars may not be easily attributable to a source Project. Some may be overtly faulty, expired and inadvertently assigned to activities from a different Project.

The worse-case scenario occurs when an existing Global Calendar is possibly overwritten by an imported Global Calendar of the same name. Just think of how many Global Calendar are named “Standard 5 Day Calendar”

In general, Global Calendars are intended to be used only for creating Project or Resource Calendars. Therefore, Global Calendars should never be transferred from one party to another.

For those submitting Project Schedules to other parties, make sure that Global Calendars are not included in the export file (typically the .XER file). Submitting Global Calendars to other parties not only populates other P6 Users with superfluous Global Calendars but is bad form and must be avoided.

For those receiving Project Schedule from other parties, make sure that the import file (typically the .XER file) does not contain Global Calendar. Otherwise, before long, your Global Calendar list will contain scores of unrecognized and unassigned Global Calendars with the potential of invalidating your CPM network.

Sadly, of the countless number .XER/.XML files I have received over the past 15 years (or so), nearly ALL of them contain references to a Global Calendar.

The reality is that most P6 Users (who may not necessarily be a “Scheduler”) don’t even realize that they are sending Global Calendars. Similarly, many P6 Users are not even aware of that the problem exists. Even then, if you’re aware of the issue, you could still be sending Global Calendars and not know how or why they are mysteriously propagating into your Export Files. Keeping Projects Global Calendar free is not as easy as you may think.

Unfortunately, there’s no export option that reads “Omit Global Calendar References”. Therefore, below, I have outlined a Step-By-Step procedure that will help you root out Global Calendars from your export files.

Step 1: Establish a naming convention that clearly distinguishes Global Calendars from Project Calendars.

In the illustration below, “**GC-99” has been added as a prefix to all existing Global Calendars. To ensure all are unique, the Global Calendar sequence was numbered from “00” to “15”. From this point forward, it will be easy to spot whenever Global Calendars are used in a Project. In addition, any new Global Calendars that have been inadvertently imported from an unvetted file can be easily and quickly identified.

Step 2: Make Sure no Activities in the Project are assigned to a Global Calendar.

Now that all Global Calendars are clearly defined, Open the Project and set the Filter ‘All Activities’. Next, Group & Sort by Calendar then collapse to ‘Calendar Level 1’. The result should appear like image below.

In the image above, it’s easy to see that Project activities are assigned to Global Calendars “**GC-00” and “**GC-06”.

From this point, reassign the activities with Global Calendars to Project Calendars.

Step 3: Make Sure all Project Calendars are not inheriting from a Global Calendars.

From the Enterprise Main Menu, select “Calendar”. The Calendar window appear as shown below displaying all the Project Calendars created for the Project.

For each Project Calendar listed, click the Modify command button to display the window shown below:

For “TS-01 – 5 Day WrkWk – Gen’l Construction w/Holidays (Thru 2018)”, the Project Calendar is inheriting from “**GC-13 – Standard 5 Day Workweek”. Revise the inheritance setting to <None>. Continue this process for all Project Calendars regardless of whether the Project Calendar is assigned to an activity or not.

Step 4: Make Sure the Default Calendar is not a Global Calendar.

Whenever a new Project is created, P6 automatically assigns the Global Default Calendar as the assigned Default Calendar for the Project. As shown below, the selected Project defaults to a Global Calendar when a new activity is added to the Project. Even if all activities are assigned to a Project Calendar, having the Default Calendar set to a Global Calendar will cause P6 to embed the Global Calendar when an export file is created.

To remove the Global Calendar as the Default Calendar, first Open the Project, then select a Project Calendar as the Default Calendar. When the Project is closed and the Project is highlighted in the Projects Tab, no Default Calendar will be shown in the textbox. To see the assigned Calendar, simply re-open the Project then return the Projects-Defaults Tab.

Step 5: If you are using Resources, make sure the are using a shared or Personal Resource Calendar.

All Resources are assigned a Calendar which can be viewed in the Details ->Profile selection window. When a new Resource is created from scratch, P6’s designated Default Project Global Calendar is automatically assigned as the Default Calendar for the Resource. In the illustration below, the Carpenter resource Calendar Profile is assigned to a Global Calendar.

Resources can either be assigned to a Personal Calendar or be assigned to a previously created Shared Resource Calendar.

To prevent a Global Calendar from making its way into the .XER/.XML file, all Resources that are assigned to the Project’s activities must be assigned to either a Shared Resource Calendar or a Personal Calendar. Furthermore, whether a Shared Resource or Personal Calendar is used, the assigned Calendar must not be inheriting from a Global Calendar (See Step 3 above).

Step 6: Use the VFR (Visual File Review) technique to verify no Global Calendar references are contained in the .XER File.

Checking an .XER for Global Calendars is easy. Simply open the file using a text editor such as Notepad then scroll down to the Calendar Table (%T) section as shown below:

Below that line, look for a Record line starting with (%R). Reading to the right, the 7^th field, which displays the record value for Field Name (%F) “clndr_type” is displayed. The three possible Record values for the Field “clndr_type” (Calendar Type) is:

CA_Base: Identifying a Global Calendar;
CA_Project: Identifying a Project Calendar;
CA_Rsrc: Identifying a Resource Calendar.

If “CA_Base” exists as a Calendar Type, then a Global Calendar exists for the Project contained in the .XER File. In this case, return to P6, then reopen the Project, then go through Step 1 through 5 until you find offending Global Calendar assignment. Although, I don’t have an .XML example, the same approach applies.

Keeping “Lean & Mean” Global Calendar free Projects helps stop the proliferation of redundant and superfluous Global Calendars.

If you find this article useful, I encourage you to pass it along to your P6 scheduling colleagues.

Reporting Changed Logic to Existing 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.