Managing “Interface” Milestones in a Master Program Schedule – The Official Site for Zümmer

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

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:

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.

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.

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.

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:

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.

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:

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.

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.

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

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.

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

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):

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.

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

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.