Category: General

Introduction

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.

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

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

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.

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:

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.

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.

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.

Since there is a FS relationship between Task A and Task B, the milestone type assignment should be apparent. Furthermore:

1. The relationship between Task A and the Interface Finish Milestone is Finish-to-Finish (FF).
2. The relationship between the Interface Finish Milestone and the Interface Start Milestone is FS.
3. 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.

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:

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.

Furthermore, in the example above, a convention is established to color-code the Impact Float value.

1. For completed Interfaces, a gray interface icon indicates that there’s no Impact Float values.
2. For circumstances where the Impact Float value is greater than 90 Days, the interface icon is green.
3. For circumstances where the Impact Float value is between 31 and 90 Days, the interface icon is yellow.
4. For circumstances where the Impact Float value is between 1 and 30 Days, the interface icon is red.
5. For circumstances where the Impact Float value is zero Days, the interface icon is blue.
6. 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.

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.

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.

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:

1. Adjust Activity A’s duration so that it completes on the previous Thursday.
2. Adjust Activity A’s duration so that it completes on the following Monday.
3. 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.

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.

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.

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:

1. Coming up with an earlier Delivery Date.
2. Re-sequencing Activity D so that it starts later than the current Delivery Date.
3. Finding a solution to eliminate the interface.
4. 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.

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.

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.

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. 

1. P6 Layout grouped by WBS showing Interface Milestones.
   

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

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.

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

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.

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.

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

1. Master Program Schedule Guidelines.

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.

Once an Interface has been determined, the interface model will exist in three schedules.

1. Once in Project A1 as shown in Figure 28 above as a Finish Milestone.
2. Once in Project B2 as shown in Figure 28 above as a Start Milestone.
3. 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

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.

When a Project is required to insert a Finish Interface Milestone (See Figure 30 above):

1. The activity name is to conform to the naming convention for Interface Milestones.
2. 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.
3. 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.

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:

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

© 2012-2025 FoxQuest Systems, Inc. All Rights Reserved                                                                                                                                        

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:

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.

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.

Since Zümmer is a report intensive application, using a PDF output device is probably the best option for printing. Of the many PDF options available, Adobe Acrobat PDF provides the best printer preference features.

The post: Streamlining the Printing Process with Adobe Acrobat details the procedures for setting up the best printing configuration found to work with Zümmer by assigning 1) an Output folder and 2) disabling the ability to view Adobe PDF results.

To date, another PDF Printer device with these features has not been found. In addition to the Printing Preference options, Adobe Acrobat allows for combining multiple PDFs into one PDF file with multiple options including bookmarking. The following steps for report combination assume:

1) Adobe Acrobat PDF is the default printer and;

2) the Adobe Acrobat PDF Printing Preferences are in accordance the topic detailing the streamlining the printing process.

Step 1: Select the Zümmer Reports to print.

In the figure below, Zümmer Analysis Reports:

a) #01 thru #47;
b) Analysis Charts 1 & 2;
c) Analysis Statistics 1 & 2;
d) Predecessor Successor Report and;
e) Project Settings

…are selected to Print for Project ID: VS2-BL4-UP13.

For this exercise, the “Include Summary” option is checked which adds the Analysis Summary Schedule report to the list. A total of 54 reports will be printed for this series.

Step 2: View the resulting output PDF files and remove all blank reports.

In the illustration below, all reports have been printed and are display by “Date Modified” in the PDF Port folder view. For this illustration, only the last 16 Analysis Reports are displayed, however, all 54 reports are contained in the PDF Port Folder.

Note: During the printing process for this exercise, the total time to print all 54 reports was under 3 minutes. Of course, results will vary depending on many factors, however, the results achieved is typical for a standard Zümmer report series.

Next, click on the “Size” column header so that the smallest reports are on the top as shown below.

In the illustration above, an additional 6 reports not shown are reporting at 6 KB in size. Most likely, the smallest PDF file sizes indicates that there were no results that satisfied the Report’s criteria.  Depending on your PC and software application configuration, zero result reports may have a different size. You can verify empty reports, by opening the first report and observing if any results are displayed.

In this configuration, a 6 KB file size indicates zero results. Therefore, all reports with a file size of 6 KB can be safely deleted. Since the file size of the remaining reports (shown below) are greater than 6 KB, they contain data and therefore will be combined into the final report.

Step 3: Combine the remaining Analysis Reports.

Next, Select All (Ctrl-A) highlights the remaining Analysis Reports, then Right-Click to display the “Combine supported files in Acrobat…” option.

In the Adobe Acrobat Combine Files window shown below, all the Analysis Reports default to sorting alphabetically by name. Note that in this exercise, report “00 summary schedule analysis” is at the top. Each of the named reports in the combined list will become a Bookmark Panel in the combined PDF file.

Next, click on the “Combine Files” shown above. The result is a combined PDF file named “Binder1.pdf” as shown below:

  Step 4: Setting Properties and renaming the Binder1.pdf file.

From the File option above, select Properties to display the Document Properties window. Then select the Page layout: option – Bookmarks Panel and Page as shown below.

Since this is schedule analysis for Project “TS2-BL4-UP13″, select File, Save As, then enter a File name such as:

VS2-BL4-UP13 – Thyme Street Building 2 – Schedule Analysis – DD 01-May19.pdf

Finally close the file, then re-open the file to display the combined PDF file in the format shown below.

The left column displays the automated named Bookmarks while the right panel displays Page 1. Clicking on the Bookmark line item causes the right panel to display the first page of the selected report.

A combined and bookmarked PDF file in this format adds an elegant and professional grade touch to your Zümmer report deliverables.

Copyright ©2020 FoxQuest Systems, Inc. – All Rights Reserved.

• Simplicity in form and function

Learning to use Zümmer is easy.

There is no prerequisite for lengthy or expensive training sessions. Most users are generating Zümmer CPM Analysis & Comparison reports minutes after installation.

Simply identify the 1) “Control” Schedule and 2) the “Modified” Schedule and you’re ready to run an Analysis Series and/or a Comparison Series of reports. It’s that simple. Each Analysis/Comparison report is well defined and many are numbered to match a line item in an optional 2-Page Summary Report.

• Streamlines and standardizes technical review time.

Running a schedule analysis or schedule comparison is easy and takes just a few minutes. The result is a series of professional grade reports, graphics and optional 2-Page summary that provides a complete profile of the CPM Schedule changes, status, quality and overall content. By performing a consistent analysis/comparison on a regular basis, you can be sure that each schedule update is of the highest quality keeping you and the project team up-to-date with the best possible and most reliable schedule information available.

• Flexibility in Series Analysis/Comparison Report Content.

You have complete control over the number of reports generated with each Analysis or Comparison Series. There’s no need to run reams of reports just to access the specific information you need. Once a selection of reports is made, you can even run the same set of reports against other Projects. Simply, return to the Project Selection Tab, reselect the “Control” and/or “Modified” Project(s) then return to the Analysis or Comparison Tab, click Print and you’re done.

• Helps to maintain a high-quality CPM Schedule.

If you prepare and/or update CPM schedules you want to be sure that your product meets or exceeds the guidelines established in the Contract Specifications. If you are responsible for receiving and reviewing schedule updates you want to know exactly what changed and quickly determine if the schedule changes are reasonable. With 88 Analysis Reports and 70 Comparison Reports, Zümmer has you covered no matter which side of the Project table you’re on.

• Protects your credibility as a Professional.

Every Project Scheduler knows the feeling of the pressures associated with delivery deadlines. When it comes to schedule updates, the Scheduler is typically the last link in the update process. It is vital that the Scheduler prepare and deliver CPM schedule updates with the highest level of confidence that all activities and activity changes are checked prior to delivery. The Scheduler’s as well as the Corporate’s reputation is at stake every time a product changes hands. Why take chances? When the Scheduler complete a schedule update, an attached Zümmer schedule analysis and comparison report not only demonstrates a high-level professionalism, but also provides the reviewer with a level of confidence that the update was performed with the highest level of care and concern for accuracy.

• Identifies cost anomalies relative to activity status.

When it comes to large schedule networks that are resource loaded, it doesn’t take long before tasks and cost get out of whack. With Zümmer’s specially designed analysis reports, cost vs. schedule anomalies are quickly identified keeping your schedules and cost data always in sync.

• Documents “Work Orders” and “Issues”.

Nearly every construction project has its share of Work Orders (or Change Orders) and Issues. Zümmer’s Work Order and Issues Modules are design to integrate with P6’s Global Activity Code feature to produce easy-to-read and well-organized reports ready for Upper Level Management’s use and review.

• Graphs and Reports activity status across multiple updates.

Identifying and communicating trends is a vital component for keeping a Project on-track.  Zümmer’s unique Activity History Module allows you to plot and/or tabulate the status of any activity across multiple schedule updates. With activity progress reporting capabilities, you can spot trends and provide Project Managers and Upper Level Management with the necessary tools to proactively respond and resolve milestone slippages. The Activity Progress Graph displays an easy-to-understand plot of data date vs. update date data points. The Activity History Report displays the Original and Remaining Duration, Start and Finish date, Total Float and Days to Complete for each Update of the selected Activity ID.

• Provides clear and concise reports useful to Upper Level Management.

Most corporate executives depend on timely and valuable information in a format that’s concise and easy to understand. Every Zümmer report is neatly designed with just the right amount of information appropriate for the topic heading. Furthermore, each report layout is developed in a consistent manner allowing the reader to quickly familiarize themselves with the data format, layout and information across multiple Zümmer reports.

Copyright ©2019 FoxQuest Systems, Inc. – All Rights Reserved