Zümmer has been a proven and successful tool for analyzing and comparing CPM schedule for over 14 years now.
Since its official release in 2012, Zümmer has never set still. Improvements to the applications features and reporting tools have been a continuing effort. Thanks in part to many suggestions received over the year by its faithful and enthusiastic users. It is our goal to continue to improve 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 CPM analysis & comparison tool can be a complicated decision for any organization and especially for larger organizations with extensive IT rules and guidelines. Therefore, our team is dedicated to making your decision as streamline as possible.
Zümmer has been tested and evaluated by some of the largest organizations in the construction industry and has passed Risk Assessment evaluation tools such as Crowdstrike Threat assessment testing with flying colors.
By definition, a Start-to-Finish relationship occurs “when the completion of the successor activity depends on the start of the predecessor activity”. The Figure above shows examples of SF relationships.
Occurrence of SF Relationships in a CPM Network
Although SF relationships are uncommon in practice, schedulers may nonetheless encounter them when reviewing CPM schedule networks. When such relationships are identified, resolving them is essential to achieving a clear understanding of the network’s underlying logic. Examining and clarifying SF links reveals the intent embedded within the schedule and ensures the network accurately reflects activity dependencies.
Avoiding Real-World Examples
Because the Forward and Backward Pass Total Float algorithm does not interpret activity names, this discussion intentionally avoids real-world examples. Introducing such examples, or attempting to justify their use, would only add unnecessary complexity to the analysis.
Sample Network Analysis
Figure 2
For simplicity, all activities in the CPM network model shown in Figure 2 are assigned to a 7-day calendar. In the sample model, WBS node “Path 2” shows that Task E is a successor to Task F through an SF relationship. The Critical Path runs through Tasks A, B, C, and D in WBS node “Path 1,” while Tasks G and H, shown in WBS node “Path 3,” each carry a Total Float value of 4 days.
Although Tasks E and F follow one another with respect to their Early Start and Early Finish dates, Task E carries a Total Float of 10 days, while Task F carries 3 days of Total Float. The SF relationship does not affect Task E’s Free Float, which remains 6 days. Because Task H’s Total Float is 4 days, Task E’s Total Float of 10 days reflects the more constraining path through Task F.
Step 1 – Resolve the SF relationship by replacing it with an equivalent Finish-to-Finish [FF] Relationship.
To resolve a SF relationship in a CPM network, first identify where it occurs. In this sample model, the SF relationship exists between Task E and Task F, where Task F is the predecessor and Task E is the successor.
In Figure 2 above, note that Task B is the driving predecessor to Task F through a Finish-to-Start [FS] relationship. Because Task F’s Early Start depends on Task B’s Early Finish, and Task E’s Early Finish is controlled by Task F’s Early Start (due to the SF relationship), it follows that Task E’s Early Finish is indirectly controlled by Task B’s Early Finish. The SF relationship between Task F and Task E can therefore be removed and replaced with an FF relationship between Task B and Task E, as shown in Figure 3 below.
Figure 3
Notice that the Total Float and Free Float values remain unchanged for all activities following this change, confirming that the CPM network stays intact and that both conventions are equivalent.
Where a lag value exists, carry it over to the FF relationship replacement. For example, an SF relationship with a 5-day lag becomes an FF relationship with the same 5-day lag.
Step 2 – Resolve the FF relationship by replacing it with an equivalent Finish-to-Start (FS) Relationship.
The next step is to resolve the Finish-to-Finish (FF) relationship between Task B and Task E. With no lag present, this scenario is classified as “FF between tasks with no lag.” This condition is discussed in detail in the article:
“The Finish-to-Finish Relationship Trap” by Lou Gonzalez. According to this article, because (a) Task B is related to Task E by an FF relationship with no lag, and (b) Task E is a predecessor to Task H by an FS relationship, the FF relationship between Task B and Task E can be safely replaced by establishing Task B as a predecessor to Task H through an FS relationship. The results of this change are shown in Figure 4 below.
Figure 4
Please note that after recalculating the CPM network, the following updates were made to Task E:
The Early Start was revised from: 14-Apr-26 to 09-Apr-26.
The Early Finish was revised from: 20-Apr-26 to 16-Apr-26.
The Total Float increased from: 10 Days to 15 Days.
The Free Float increased from: 6 Days to 11 Days.
As outlined in the referenced article, because neither Task B nor Task E governs the Early Start of Task G, the appropriate relationship for both with respect to successor Task G is FS with zero lag.
Where a lag exists — for example, where Task B is a predecessor to Task E with an FF lag of 3 days — consider splitting Task E into two tasks (E1 and E2), with E1 lasting 4 days and E2 lasting 3 days. Task E1 then becomes a predecessor to Task E2 through an FS relationship, and Task E2 becomes a predecessor to Task B through an FS relationship. Refer to the article “The Finish-to-Finish Relationship Trap” by Lou Gonzalez for more details on this procedure.
Conclusion
SF relationships are uncommon and generally discouraged in CPM network development, as their use can introduce unnecessary complexity. Nevertheless, they may appear in a CPM network, particularly due to technical considerations or unresolved dependencies between milestones.
SF relationships typically obscure the true logical connection between activities. Applying the step-by-step approach described above helps to clarify the underlying relationship within the CPM network structure.
While resolving SF relationships can sometimes be accomplished with fewer steps, a systematic procedure such as the one outlined above is preferred, as it minimizes the risk of errors when revising CPM logic.
Clearly identifying and documenting any changes made to the schedule logic is essential for transparency and justification. One solution is to run Zümmer’s Comparison Report #10, “Added Deleted Predecessors (By Activity ID),” as shown in Figure 5 below. The report documents the removal of the SF relationship between Task F and Task E, which was replaced by the more appropriate Finish-to-Start (FS) relationship between Task B and Task H.
Schedule Compression Index (SCI) is a CPM industry standard metrics designed to quantify the value of “schedule compression” that has occurred between either 2 schedule updates or 1 update and the baseline schedule. Deriving the Schedule Compression Index for any Project works best when there are minimal activity count changes between the 2 selected updates.
For example, if the selected Modified Project has the same number of activities as the selected Control Project, then the SCI will yield a more accurate result. Whereas, if the number of activities between the 2 Project updates are significantly different, the SCI value will be less accurate.
In the figure above, the Control Project’s update shows Activity A in progress with successors Activities B, C and D. In the Modified Project’s update, Activity A is complete, however later than compared to is Control Early Finish date. The Modified’s Project Update overall completion is maintained by reducing the remaining duration in Activities B, C and D. Therefore, by observation, the Modified Update reflects a level of schedule compression to maintain the Project Finish date.
In the figure above, the equation to calculate the SCI is shown. Note that the Remaining Early Start Date (RES) is calculated by subtracting the Remaining Calendar Duration from the Control Early Finish date. Since Activity B is “in progress” in the Modified update, the RES is later than Activity B’s Early Start. This allows for taking account for partial progress achieved in the Modified Project’s update.
Ƶümmer’s Schedule Compression Index Report, shown above, displays each task that is not complete in the Modified Project’s update, then shows the Remaining Calendar Duration, Control Remaining Early Start (RES) date, “Control Early Finish” (CEF) date, Modified Early Start (MES) date and Modified Early Finish (REF) date. At the completion of the listing, the Minimum RES, Maximum CEF, Minimum MES and Maximum MEF dates are calculated. Below that, the overall durations for the SCI calculation are shown. In the example below the Schedule Compression Index is shown as 41.61%. Finally, the RES and SCI equations are shown at the bottom of the report.
If you really want your PMs to throw your schedules in the trash, make your activity descriptions hard to read. One naming convention I use is to place the “Subject” before the “Action”. In the figure above, the 2 WBS nodes show activities created from the same fragnet.
In the top node, the scheduler, pasted the “Roadway M” to the end of the fragnet description. Although this might be faster, it typically detracts from the readability of each activity. In the bottom node, “Roadway M” was abbreviated as “Rdwy M” and placed before the action item. Note how much easier it is to read, making your schedule easier for the user to comprehend. This is a simple example but imagine a more extensive fragnet with longer action descriptions easily making things worse. Don’t be lazy; spend the extra time to format your activity descriptions in a more readable way. Not only will your schedules be better understood by your audience, but you’ll stand out as a premier P6 scheduler.
In most multi-projects programs or complex projects, tasks or resources are often dependent upon other tasks, resources, constraints or hand-offs that are not part of the project itself. These dependencies are often described as external relationships. For example, a separately contracted utility project’s trench installation may restrain another bridge construction project’s ability to start their pile driving operation. Since the sequence of operation requires work from one project to complete so that another project can start their work, the hand off task relationship spans projects. These types of relationship in a Critical Path Method (CPM) schedule are typically defined as “Interfaces” or “Interdependencies”. For the purposes of this article, we will use the term “Interface”. However, keep in mind that the term “Interdependency” may be used as well to mean the same thing or even used interchangeably. In a CPM schedule, Interface Milestones require special attention and should be maintained and monitored in a specific and organized manner. Interface Milestones are typically found and maintained in a Master Program Schedule (MPS). Therefore, before diving into Interface Milestones, we need to briefly discuss Master Program Schedules.
What is a Master Program Schedule?
A Master Program Schedule (MPS) is a CPM schedule developed for very large projects (sometimes defined as a “Program”), typically consisting of multiple projects, contractors, designers and engineers. Programs usually employ a Project/Program Controls Teams under which a Scheduler or Schedule Team is responsible for developing and maintaining the MPS.
Figure 1
In Figure 1 above, the MPS is organized so that the Work Breakdown Structure (WBS) is leveled as shown where Level 1 is the Program; Level 2 contains Project Groups such as Building construction, Roadway construction and Waterfront Construction; and Level 3 contains the multiple projects under each Project Group.
MPS projects typically span stages to include Planning, Design, Bid & Award, Construction and Close-out. The Planning, Design Bid & Award and Close-out stages are typically detailed to contain tasks at their lowest level. The Construction Stage typically contains a summarized version of a detailed construction schedule that is maintained by another party such as the General Contractor. Since the MPS contains a collection of Projects for a construction Program, it is an ideal place to manage, monitor, maintain and report Interface Milestones.
TERMS AND DEFINITIONS
Interface Milestone: Interface Milestones are used when the start of a task from one project depends on the completion of a task from another project.
Figure 2
In Figure 2 above, the start of Project B2’s Task B is dependent upon the completion of Project’s A1 Task A. In CPM scheduling terms, there is a Finish-to-Start (FS) relationship between Task A and Task B. Since Task A belongs to Project A1 and Task B belongs to Project B2, then in can be said that there is an “external” restraint impacting the start of Task B. To model this condition in a MPS schedule, Interface Milestones are inserted between Task A and Task B.
Figure 3
In Figure 3 above, interface milestones are shown inserted between Task A and Task B. Since there is a FS relationship between Task A and Task B, the successor Interface Milestone type for Task A is a Finish Milestone and the predecessor Interface Milestone type for Task B is a Start Milestone.
2. “Delivery” vs “Need” Project/Date:
Figure 4
In Figure 4 above, Project A1 is defined as the “Delivery Project” while the Finish Date for Task A is defined as the “Delivery Date”. In addition, Project B2 is defined as the “Need Project” while the Start Date for Task B is defined as the “Need Date”. If Project A1 and Project B2 are part of the same CPM schedule, the typically an Activity Code is created to designate activities assigned to Project A1 and Project B2. In this scenario, Task A and the Finish Interface Milestone are assigned with the Activity Code for Project A1 and Task B and the Start Interface Milestone are assigned with the Activity Code for Project B2.
3. Impact Float:
In Figure 4 above, The Delivery Date of Task A is shown as driving the Need Date of Task B. However, internal tasks that are assigned to Project B may drive and control the Need Date of Task B.
Figure 5
In Figure 5 above, Task B’s start date is controlled by an internal task (not shown) assigned to Project B2. In this scenario, the Impact Float is defined as “the difference between the Delivery Date and the Need Date”.
The Impact Float is typically measured in calendar days and with some exceptions (to be discussed later), can be determined by observing the Free Float value of the Start Interface Milestone. Additionally, when the Need Date is later than the Delivery Date, the Need Date can be determined by adding the Impact Float value to the Interface Start Milestone’s date.
RULES AND CONVENTIONS
Rule #1: Interface Milestones exist in pairs and are between 2 different Projects.
What constitutes a “Project” is generally user defined. Since P6 classifies a CPM Schedule as a “Project” with a unique Project ID, the description for a project may be somewhat confusing or redundant. Often, in a large CPM network, Activity Codes are used to classify activities into different categories. Therefore, a typically large CPM network would have an Activity Code to sort or group the work into a secondary level such as “Sub-Project” or ‘Area” or “Contractor”.
This Activity Code convention would then be useful in identifying the 2 different projects used for an Interface Milestone.
Figure 6
In Figure 6 above, the Interface Milestone pair is shown above inserted between Task A and Task B.
Rule #2: The Delivery Project’s Interface Milestone is a Finish Milestone and the Need Project’s Interface Milestone is a Start Milestone.
Figure 7
Since there is a FS relationship between Task A and Task B, the milestone type assignment should be apparent. Furthermore:
The relationship between Task A and the Interface Finish Milestone is Finish-to-Finish (FF).
The relationship between the Interface Finish Milestone and the Interface Start Milestone is FS.
The relationship between the Interface Start Milestone and Task B is Start-to-Start (SS).
Rule #3: SS and FF relationships do not constitute an interface.
Figure 8
Interfaces are meant to be used when there is a hand-off of work from one project to another. Any other relationship type, either SS or FF, does not correctly model the intended workflow from one project to another.
Rule #4: The interface description generally follows the structures syntax defined below:
Figure 9
Since there are 2 parties involved in an interface, it is important to ensure that the interface activity description clearly describes a) the Project A1 scope that needs to complete and 2) the Project B2’s scope that is waiting to start. The word used to separate both scopes is “allows”. “Enables” can be used as an alternative depending on the party’s preference.
Below is an example of a correctly constructed Interface Milestone activity description:
“Transport Agency – Elevated frontage roadway complete allows Terminal Contractor – Terminal A curbside construction to start”
It is suggested that the word “Allows” (or “Enables”) be used only in conjunction with interface milestones. Keeping “Allows” as a reserved word is especially helpful when filtering for interfaces in P6. For example, a filter such as, “Activity Name” contains “Allows” is simple way of selecting all interface pairs.
Rule #5: Each Interface Milestone shall be uniquely identified using an Activity Code convention.
The Activity Code convention can take the form of any format that works best for the Project’s environment or reporting needs. Also, the Activity Code chosen, can be either “Global” or “Project”. In Figure 10 below, the coding is constructed so that there is a 2-letter prefix describing the type of interface milestone indicating if the milestone is contractual and/or includes liquidated damages; and a 3-digit unique number.
Figure 10
Furthermore, in the example above, a convention is established to color-code the Impact Float value.
For completed Interfaces, a gray interface icon indicates that there’s no Impact Float values.
For circumstances where the Impact Float value is greater than 90 Days, the interface icon is green.
For circumstances where the Impact Float value is between 31 and 90 Days, the interface icon is yellow.
For circumstances where the Impact Float value is between 1 and 30 Days, the interface icon is red.
For circumstances where the Impact Float value is zero Days, the interface icon is blue.
For circumstances where the Interface is unresolved, the interface icon is black, and the code is prefixed by the letter “U”.
SCENARIOS AND IMPACT FLOAT
Scenario 1 – Impact Float value is more than 90 Days.
Figure 11
In Scenario 1, the Delivery Date is significantly earlier than the Need Date. In this Scenario, maintenance can be limited to general housekeeping tasks, making sure that the logic still holds and that the interface is still valid. Include in Active Interface Milestone report(s).
Scenario 2 – Impact Float value is between 31 and 90 Days.
Figure 12
In Scenario 2, the Delivery Date is nearing the Need Date and within the range where some concern should be recognized. In the Scenario, maintenance should include general housekeeping tasks, with follow-up with both Project Managers making sure that the logic still holds and that the interface is still valid. Include in Exceptions Active Interface Milestone report(s).
Scenario 3 – Impact Float value is between 1 and 30 Days.
Figure 13
In Scenario 3, the Delivery Date is very near the Need Date and within the range where concern should be recognized. In this Scenario, follow-up with both Project Managers maintenance is required, making sure that the logic still holds and that the interface is still valid. Include in Exceptions Active Interface Milestone report(s).
Scenario 3 – Calendar assignment issues generating Impact Float around 2 Days
Additionally, when the Impact Float value is in the range of about 2 days, special care must be taken to make sure the impact float is not due to calendar assignment issues. For example, in Figure 13 above, if Activity A and Activity D are on a 5 Day calendar and Activity A completes on a Friday, the Interface Delivery Date Finish Milestone (being on a 7-day calendar) will show finishing on a Friday and the Interface Start Milestones (being on a 7-day calendar) will show starting on a Saturday. Also, if the interface Start Milestone is driving Activity D, then Activity D will show starting on Monday. In this case, the Interface Start Milestone will show 2 days of impact float. Solutions include:
Adjust Activity A’s duration so that it completes on the previous Thursday.
Adjust Activity A’s duration so that it completes on the following Monday.
Adjust Activity D calendar assignment to a 7 Day Calendar.
Consequentially, these changes will cause this interface to move from Scenario 3 to Scenario 4 discussed below.
Scenario 4 – Impact Float value is 0 Days.
Figure 14
In Scenario 4, the Impact Float is zero which means that the Delivery Date is later than the Need date. Note in Figure 14 above, the start of Activity D is restrained by Project A1’s Activity A instead of Project B2’s Activity C. In other words, Activity D is being restrained by an external activity originating from Project A1.
Whether action is necessary to resolve this issue may depend on several factors. The first thing that should be considered is whether there is Total Float remaining in Activity D. For example, if the Total Float value is very large, then this may be an acceptable scenario, and no action may be required. Secondly, consideration should be taken to determine the amount of mitigation that would be required to Activity A so that Activity D is now restrained by Activity C. In this case, determining how much mitigation would be required. The amount of mitigation can be determined by the difference between the start date of Activity D and the finish date of Activity C. If the amount of required mitigation is prohibitively large, then mitigation may not be possible. Otherwise, if the amount of mitigation is small, then it may be possible to accelerate Activity A so that it finishes before the completion of Activity C.
Resolving Scenario 4 requires participation between Project Managers from both projects to work out how much mitigation could be initiated or to leave as is and monitor from update to update. In this Scenario, follow-up with both Project Managers maintenance is required, making sure that the logic still holds and that the interface is still valid. Include in Exceptions Active Interface Milestone report(s).
Scenario 5 – Early Need Date vs Late Need Date.
Figure 15
In certain cases, the Early Need Date as shown in Figure 15 above may not be an appropriate date report. Scenario 5 occurs when the Free Float value of Activity C is so large that reporting the Early Start of Activity C may result in a misleading Need Date that is much earlier than anyone can reconcile or understand.
In these cases, the responsible scheduler or Project Team may elect to report a later Need Date that better represents the situation. The method to report a later Need Date involves assigning an As Late as Possible constraint to Activity C then recalculating the CPM schedule.
In Scenario 5, with Activity C constrained As Late as Possible, a later Early Start date, or the Late Need Date can be reported as a viable alternative. Note that in Scenario 5, the resulting Impact Float value between the Interface Start Milestone and the Late Need Date is greater than the Impact Float value when Activity C is not constraint by As Late as Possible. The 2 Impact Float values will differ by the Original Duration of Activity C.
Scenario 6 – Interface is Unresolved.
Figure 16
In Scenario 6, the interface is classified as “Unresolved”. Note in Figure 16 above, the Delivery Date is later than the Need Date. In this scenario the Finish Milestone is not restraining the Start Milestone interface pair. In unresolved scenarios, the relationship between the Delivery Date and the Need Date may not be immediately implemented so as not to delay the start of activity D until such time as the Interface can be resolved. Typical solutions include:
Coming up with an earlier Delivery Date.
Re-sequencing Activity D so that it starts later than the current Delivery Date.
Finding a solution to eliminate the interface.
A middle ground combination of a) and b).
Since in Scenario 6, the Need Date Start Milestone is earlier than the Delivery Date Finish Milestone, the mitigation duration required can be determined by setting the Need Date as a predecessor to the Delivery Date. The Need Date’s Free Float value will calculate to the required mitigation’s duration. The downside to this method convention is that the relationship is Start-to-Finish which may be flagged as violating best-practice standards. Considering the benefits of being able to determine the required mitigation duration and of maintaining the interface milestone convention, this should be an acceptable approach and not detract from the CPM’s best-practice score.
Scenario 7 – Completed Interface.
Figure 17
In Scenario 7, as shown in Figure 17 above, the specified interface has been satisfied and has been statused as completed. Notice that since the interface is complete and satisfied, both Start and Finish Milestone must be statused as complete at the same time. If during your housekeeping procedures, for example, if the Finish Milestone is actualized but the Start Milestone is not (or visa-versa), then there is an inconsistency in status which must be resolved. In addition, since the Finish Milestone normally completes at the end of the day and the Start Milestone starts at the beginning of the day, then for example, if the finish date is statused as complete on 15-May, then the Start Milestone can be statused as started on 16-May.
Scenario 8 – External Delivery Interface.
Figure 18
In Scenario 8, an “External” Delivery Project or Agency restrains a Project task in the MPS. By “External”, we are referring to a Project, Agency or Entity that does not exist in the MPS however, has an influence that restrains the start of a task in the MPS. An External Delivery Project typically includes Projects that are not modeled in the MPS. External Agencies typically include a Utility Service (i.e. Water, Power, Sewer, Network) either, Local, State or Federal, that is required for the successor task in the MPS to start.
In this scenario, as shown in Figure 18 above, the Interface Pair is added as usual. However, the Finish Milestone is assigned a Finish On or After constraint to match the known completion date of the restaining task. To aviod an open-end condition, the Finish Milestone will be assigned some non-driving predecessor such as Project Notice to Proceed or Project Start. The Finish Interface Milestone can reside in a WBS node for the External Delivery Project or Agency.
Scenario 9 – External Need Interface.
Figure 19
In Scenario 9, a Project Task in the MPS restrains an “External” Project or Agency that is not modeled in the MPS. By “External”, we are referring to a Project, Agency or Entity that does not exist in the MPS however, is restrained by the completion of a task in the MPS. An External Need Project typically includes Projects that are not modeled in the MPS. External Agencies typically include a Utility Service (i.e. Water, Power, Sewer, Network) either, Local, State or Federal, that is dependent upon the completion of a task in the MPS.
In this scenario, as shown in Figure 19 above, the Interface Pair is added as usual. However, an additional Start Milestone is assigned a Start On or After constraint to match the known need date for the successor External Entity. The added Start Milestone’s constraint represents the known need date that matches External Entity’s requirements. Therefore, the Impact Float can be determined in the same way as any other Interface Start Milestone component. The added Start Milestone can reside in a WBS node for the External Need Project or Agency along with the Interface’s Start Milestone pair.
INTERFACE MILESTONE REPORTS
Reporting on the status of interface milestones is an important step in the scheduling process. How you report on them will contribute to the success of the project(s) or Program you are scheduling.
There are many options on how reports are produced and the method you choose will depend on many factors. Such as, the reporting requirements for the project, the reporting requirements requested by your audience, your reporting skill set, the project specification requirements and others. In this section we’ll explore options and suggestions available in P6, but there are many other options. The means and methods are not as important as the output provided to your audience. Therefore, this article will not discuss how to generate the non-P6 layout reports but provide you with tried-and-true output reports that may spark your imagination and problem-solving capabilities. While Report 1 is generated by P6 and Report 2 is created manually and can be generate with applications such as PowerPoint, Visio, AutoCAD or some other graphics orientated tool. Reports 3 through 7 can be automatically generated from the data entered in P6 alone using a database or report writing application.
P6 Layout grouped by WBS showing Interface Milestones.
Figure 20
In Figure 20 above, a P6 layout is created for an MPS. The grouping used is by Work Breakdown Structure (WBS). Notice that Levels 1, 2 and 3 are in accordance with Figure 1 in this article. WBS Level 4 is configured for Project Milestones. Since there may be various types of Project Milestones, WBS Level 5 is created to contain Interface Milestones. Since a Project can contain both incoming (Start Milestone) and outgoing (Finish Milestones), WBS Level 6 is created to group Start Interface Milestones separate from Finish Interface Milestones. WBS Level 7 is optional when needed to categorize Start or Finish Interface Milestones when necessary.
Note that the Interface Milestones are placed at the top of the WBS for the Project within the MPS. It’s idea to position the Interface Milestones at the top of the WBS so that the reader or Project Manager can see the status of the Interface Milestones at first glance. Placing the Interface Milestone at the top of the WBS also emphasizes the importance of these milestones.
At a minimum, the layout should include Activity ID, Activity Name, Start and Finish dates. In addition, columns can be added to show the Total Float and Free Float value. Remember that the Free Float value for the Start Interface Milestone pair carries the “Impact Float” value. Since we assign Interface Milestones to a 7-day calendar, and the Start Milestone Start Date represents the Delivery Date, then adding the Free Float value to the Start Date will return the Need Date for the specific Interface.
2. Interface Graphics Report
Figure 21
Figure 21 above shows an ideal solution to showing interface milestones with a summary bar for construction. In the example above, Projects A1 and B2 have 2 different interfaces designated as #1 and #2. Since the different between the Delivery Date and Need Date for Interface #1 is in the range of 30 to 90 days, the milestone symbol is yellow, and the connecting line is dotted. Similarly, there is no Impact Float for Interface #2, therefore the milestone pair is shown as blue, and the connecting line is solid. Although this document is extremely time-consuming, it is quite useful in displaying all active interfaces in one place.
3. Interface Detail Report grouped by PM.
Figure 22
An ideal report for Interface Milestones includes one that is grouped by Project Manager as shown in Figure 22 above. In a construction Program scenario, typically, there are multiple Project Managers with some potentially managing multiple projects. In this report Interface Milestones are first grouped by Project, then sub- grouped by Need/Delivery Milestone. The interface detail report about displays the counterpart Project Manager. In addition, the Delivery Interface Milestone Finish Milestone is displayed with a down arrow and the Interface Start Milestone is displayed with an up-arrow. As shown in the Legend, the color of the Interface in dictates the Impact Float value.
4. Interface Status Report sorted by ID Number.
Figure 23
Another ideal report for Interface Milestones includes one that is listed by Interface ID# as shown in Figure 23 above. In a construction Program scenario, typically, there can be numerous Interface Milestones. Therefore, a list showing them in a tabular format can be a valuable tool for reviewing them all in one place. In this report, the Interface Milestones data includes a column that sorts by Interface ID number then lists the Interface ID, Interface Description, Delivery Project Name, Delivery Project’s Project Manager, Impact Float, color coded right arrow, Need Date, Need Date Project Name, and Need Project’s Project Manager name. Note that in this example.
5. Interface Matrix Report
Figure 24
The Interface Matrix Report shown in Figure 24 above is intended to display all the Interface Milestones on one page. In addition, this report allows you to quickly determine which projects have the most interfaces with other projects. For example, the Roadway project in the Project Need column above interfaces with 4 other projects, more than any other project. In addition, note that arrows point to the left indicating the Need Projects are listed on the left while the delivery projects are listed along the top row. In this example, each project is identified by a unique “Alpha-Key” style ID. Also, each Project Group is color-coded for the Need and Delivery Project. The first column lists all Need Projects, and the remaining narrow columns show all the Program’s columns. Since there’s not enough room in the Delivery Project columns, a legend or table reference key may be added to the bottom of this report if necessary.
6. Project Progress Timeline grouped by Project ID PowerPoint format.
Figure 25
The Project Progress Timeline shown in Figure 25 above is a unique solution to show Baseline vs Forecast schedule variances in lieu of showing Baseline vs schedule variances directly from a P6 layout. In the sample above, interfaces are shown with either up or down colored arrows. Down arrows are used to represent the Finish Milestone pair of the Interface while Up arrows represent the Start Milestone pair of the interface. Both up and down arrows are placed in time based on the Delivery Date while the arrow’s color indicate the available impact float value’s range. Below each arrow, the Interface ID is shown. Furthermore, the arrows in the Forecast section show the variance in calendar days compared to the Baseline date. Due to spacing limitations, the Interface description is not shown. Therefore, a legend may be useful.
7. Project Timeline with Detailed Interface table.
Figure 26
A solution to showing Interface descriptions along with summary project status bars is shown in Figure 26 above. The sample shown can be produced in MS PowerPoint and automatically populated from P6 data using the features available in Microsoft Office Automation. Below the timelines project bars are color-coded to show Design/Planning, Procurement (Bid & Award) and Construction phases. Below the Project bar, an Interface table is produced showing the Interface ID, Interface Milestone description, Delivery Date, Impact Float, Need Date, Status and notes for a Mitigation plan if necessary. In the Status column above, interfaces are shown with either up or down colored arrows. Down arrows are used to represent the Finish Milestone pair of the Interface while Up arrows represent the Start Milestone pair of the interface.
GUIDELINES FOR MANAGING EXTERNAL SCHEDULES WITH INTERFACES
Master Program Schedule Guidelines.
Figure 27
In a construction program environment where an MPS has been developed, typically, CPM schedules are developed for the subset construction projects and are used to update the MPS monthly as shown in Figure 27. Typically, also, for the construction phase in the MPS, a summarized version of the construction activities are contained in the MPS. How the detailed construction activities in the Project schedule are summarized in the MPS is a topic beyond the scope of this paper. Coordinating, maintaining, reporting and updating Interface Milestones is a vital component in achieving a successful construction Program.
Therefore, it is important to include specific instructions in each Project’s scheduling specifications. Below are some guidelines that can be used to ensure interface milestones are maintained in the Project Schedule so that the Master Program Schedule can effectively report on the status of each defined interface. These guidelines also ensure that the insertion of interface milestones in external project are done in such a way as to make sure that CPM network can function properly (i.e. calculating Total Float) with or without the presence of interface milestones.
As explained earlier in this article, Interface Milestones exist in pairs. Once as a Finish Milestone for the Delivery Project and once as Start Milestone for the Need Project as shown below in Figure 28. Since Projects A1 and B2 are separate projects with separate schedules, the finish and start interface milestones are handled differently in accordance with these guidelines. Also, as shown in Figure 28 below, since each project is contained in a separate CPM network, the milestones are not logically related and there is no relationship tie between the Delivery Project’s Finish Milestone and the Need Project’s Start Milestone.
Figure 28
Once an Interface has been determined, the interface model will exist in three schedules.
Once in Project A1 as shown in Figure 28 above as a Finish Milestone.
Once in Project B2 as shown in Figure 28 above as a Start Milestone.
Both Start Milestone and Finish Milestone for the specific Interface will exist in the MPS.
Activity Codes
In the MPS, an Activity Code (either Project or Global) should be established that maintains the comprehensive list of all created Interface Milestones throughout the life of the Program. The Interface Milestone Activity Code shall have a unique Activity ID Code with an appropriate Activity Code description that is in accordance with Rule #4 and #5 as outlined in the Rules and Conventions section above.
User Defined Fields
In the MPS, a User Defined (UDF) Code should be established that maintains the external Activity ID that is used in Projects A1 or B2. This allows the cross-reference between the activities created in the MPS and the source activities in either Project A1 or B2.
WBS Interface Milestone Node
Figure 29
In the MPS, (as shown in Figure 29 above) an Interface Milestones Node should be created for each Project. Subset nodes should also be created to group Start Interface Milestones and Finish Interface Milestones. The Interface Milestones node should be placed at the top and at the next level just below its parent Project Level node. By placing the Interface Milestone node at the top, above Planning, Design, Procurement and Construction, etc. Project Managers will see this as the first set of schedule data, placing a high priority of importance to this information. Additional nodes can be placed below the Start/Finish Interface Milestone node to categorize various types of Start/Finish Interface Milestones such as Building, Roadway, MEP, etc. Start/Finish Interface Milestones.
2. Guidelines for a Finish Interface Milestone in an External Schedule.
Figure 30
When a Project is required to insert a Finish Interface Milestone (See Figure 30 above):
The activity name is to conform to the naming convention for Interface Milestones.
The predecessor activity or activities shall consist of all Project A1 activities that restrain the Finish Interface Milestones. Since this is the Interfaces Finish Milestone pair, the predecessor relationships should be Finish-to-Finish.
The Finish Interface Milestone should have the same successor activities as its predecessor tasks. This ensures that the Total Float value is correctly calculated.
Activity Codes
In the Project schedule, an Activity Code should be established that maintains the comprehensive list of all created Interface Milestones throughout the life of the Project. The Interface Milestone Activity Code shall have a unique Activity ID Code with an appropriate Activity Code description and be consistent with the Interface Milestone Activity Code established in the MPS.
3. Guidelines for a Start Interface Milestone in an External Schedule.
Figure 31
a. If a start date is NOT provided, then assign an “As Late as Possible” (ALAP) constraint to the Start Interface Milestones. For whatever reason, there are times when the Delivery Project is either not able or unwilling to provide a Delivery Date. In those cases, assigning an ALAP constraint will provide the drop-date of when the Delivery Task is needed.
b. If a start date IS provided, then assign a “Start on or After” constraint using the date provided.
c. Only 1 predecessor to the Start Interface Milestone is toll be assigned and it shall be any non-driving activity. Select an activity that is significantly earlier than the start of Task A. Since interfaces typically occur during construction, a milestone such as Notice to Proceed or Start Construction should work fine.
d. The successors to the Start Interface Milestone shall be all tasks that are restrained by the Interface. Use a Start-to-Start relationship for all successor relationships.
e. In the example shown in Figure 31 above, all immediate successors to the Start Interface Milestone must have at least 1 predecessor originating from the Project A1 schedule. Note in this example, Task B is preceded by Task A (Finish-to-Start) and the Start Interface Milestone; and Task C is preceded by Task A (Finish-to-Start) and the Start Interface Milestone.
Activity Codes
In the Project schedule, an Activity Code should be established that maintains the comprehensive list of all created Interface Milestones throughout the life of the Project. The Interface Milestone Activity Code shall have a unique Activity ID Code with an appropriate Activity Code description and be consistent with the Interface Milestone Activity Code established in the MPS. The Activity Code established can either be a Global or Project as long as it is in accordance with the Project specifications.
SUMMARY
In major construction projects, the latest trend is to move towards a Program management strategy where multiple contractors are hired to perform specific scopes. Another popular strategy involves a Private-Public Partnership, typically referred to as “P3” projects. In these environments coordination between the parties and their work is a vital component to a successful outcome. Identifying and managing interfaces between work scope is a mission-critical component towards that successful outcome.
Some benefits from incorporating an interface milestone strategy include:
Prevents Project Managers from being blind-sided.
Probably, the worst scenario for a Project Manager is when their near-term work plan is interrupted by another Project’s work. Not only is the affected Project’s work delayed, but other internal resources are affected.
2. Improves coordination between Project Managers avoiding potential schedule slippage.
Having a report that lists project interfaces, and their Impact Float value is a valuable tool for any Project Manager. A well-constructed and organized Milestone Interface report and procedures allows Project Managers to work interactively to plan work sequences, spot potential impacts and promote good communication between team members.
3. Improves the PM’s understanding of risks to the Project’s completion date.
When Project Managers actively engage in developing and coordinating project interfaces, project risk is reduced by effectively and efficiently scheduling and planning work sequences and resource allocations.
4. Facilitates Managements ability to maintain a proactive base approach to managing the Project(s).
By understanding project interfaces and quantifying their impact float, management is equipped with the ability to coordinate Project Managers and Teams to ensure parties are actively communicating and meeting to monitor interfaces. Furthermore, the level of management ensures that hand-offs are performed in a timely manner that best allows the projects to proceed as smoothly as possible.
5. Helps to provide a better understanding of the Project.
Working through identify and describing project interface points, Project Managers gains an increased insight in the complexity of their project thereby providing a better understanding of the challenges involved in completing the project on time and within budget.
Introducing a new module designed to help analyze logic changes to any selected activity across multiple schedule updates.
1. Activity Logic History Module Basics
The Activity Logic History Module is a powerful yet simple tool that allows you to track the logic status of any activity across multiple Project Schedules. There are a few prerequisites that must be set for the Activity Logic History Module to work properly.
Ƶümmer assumes that the Project Schedules used in the Activity Logic 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 to a Project Schedule and you want to use the assigned Project Schedule for Activity Logic History analysis, then restore that Project Schedule and place it in one of the selected EPS nodes.
In the illustration below, 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 “SR32S” does not have any Project Schedules while EPS Nodes “SR32-Q1” and “SR32-Q2” have 3 Project Schedules each.In the illustration below, 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 “SR32S” does not have any Project Schedules while EPS Nodes “SR32-Q1” and “SR32-Q2” have 3 Project Schedules each.
A well-conceived EPS as shown below is very helpful in performing Activity Logic History analysis.
The next step is to identify the Project Schedules to be used in the Activity Logic History analysis. Typically, this involves using multiple Project Schedules updates for the same Construction Project. In the illustration above the SR32 South Project has 12 monthly updates in 4 different Quarterly EPS Nodes.
In Ƶümmer, the next step is to define the EPS Nodes that will contain the Projects that will be used for the Activity Logic History Analysis. As illustrated below, from the Main Menu, select Settings-> Activity Logic History.
Once selected, the Activity Logic History Settings displays as shown below. The Available Nodes listbox on the left alphabetically displays all EPS Node that contain at least 1 Project Schedule. 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 Node “SR32-Q1” have been selected. A maximum of 10 EPS Nodes can be selected for the Activity Logic History analysis. Click OK when the all the EPS Nodes have been selected.
When the OK button is clicked, Ƶümmer saves the Selected Nodes for Analysis Activity Logic History Reporting. In addition to the Selected Nodes, all Projects under the selected nodes will be used for the Activity Logic History analysis. Therefore, In the example above, Projects: SR32-UP45, SR32-UP46, and SR32UP47, and all the activities within these Projects will be considered in the Activity Logic History Module analysis.
2. Activity Logic History List
Once the EPS nodes are selected using the Settings->Activity Logic History option, the Activity Logic History Module is ready for use.
When the Activity Logic History Module Toolbar button is clicked, the Activity Logic History window is displayed as shown below.
Within the Activity Logic History window, the “Activity List” List Box is displayed along with the Activity ID Textbox and Search Button, the Activity ID and Activity Name grid.
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 Logic 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 “C-1-1-R291” 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 Schedules. In the example above, two Activity Names for Activity ID “C-1-1-R291” occur in the Project Updates/Baseline under the selected EPS nodes. When different Activity Names exist for the same activity, the selected Activity Name appears in the report header section.
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 above, Activity ID “C-1-1-R431” is highlighted and therefore the Activity ID/Activity Name to be reported.
3. Activity Logic History Report
The Activity Logic 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 Logic History Module, lists all the activities that exist across all the Projects under the selected EPS node(s) defined in the Activity Logic History Settings.
In the illustration above, Activity ID “C-1-1-R441” is selected. From this point, you have the option of Printing or Previewing the activity logic history for the selected Activity ID across the Project Schedules that exist under the Selected EPS Node(s). In the following page, you can see the report created for this module.
Clicking on the Print command button shown above produces the Activity Logic History Report for the selected Activity ID. (See illustration below).
The Activity Logic History Report shows the Selected Activity ID and Name in the Page Header in the tan colored band. The report then groups the Logic History by Project ID shown under the green band and the selected Activity ID and Name in the light red band. Note that the Activity Name may be different under the grouped Project Schedule.
For the selected Activity ID for each Project Schedule, the Activity ID, Activity Name, Original Duration (OD), Remaining Duration (RD), Actual Start (AS), Actual Finish (AF), Early Start (ES), Early Finish (EF), Late Start (LS), Late Finish (LF)Activity Type, Driving Path Indicator (DP) and Total Float (TF) are shown.
Below each Activity ID under each Project Schedule, the Predecessors are listed first and then the Successors are listed. Predecessor are listed in blue, while the Successors are listed in red. For each Predecessor/Successor the same information is provided as for the Activity ID. In addition, the Relationship Type (Rel) and Lag (Lag) are shown.
In the example shown above, the Successor for selected Activity C-1-1-R431 in Project Schedule SR23S-45 is Activity “C-1-1-1-R441 – CE Access – Place Asphalt”. However, In Project Schedule SR23S-46, the Successor was changed to Activity “C-1-1-R1551 – CE Access – Final Grading for Sod”. Then in Project Schedule SR23S-47, the Successor was changed again to Activity “C-1-1-R1561 – CE Access – Performance Turf Sod”.
Clicking on the Preview command button allows you to preview the report as shown above prior to actually printing the report.
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.
Figure 2 – Zümmer Analysis Report [14]
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.
Figure 3 – Zümmer Analysis Report [15]
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.
Figure 6 – Zümmer Analysis Report [35]
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.
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.
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 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 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.
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:
Improved Item Settings management
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.
