September 2022 – The Official Site for Zümmer – CPM Schedule Analysis & Comparison

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.