The Precedence Diagram Method (PDM) provides several ways to define relationships between activities. However, schedulers may incorrectly use these options in ways that allow logic to bypass one end of an activity. Two common examples:
No Finish-Side Successor: no relationship carries logic out of the activity’s finish.
No Start-Side Predecessor: no relationship carries logic into the activity’s start.
These two patterns mirror each other, so this article covers both. It explains:
how each pattern creates an activity that is open-ended in practice,
why P6’s standard filters don’t catch them, and
how Ƶümmer detects, identifies and reports them.
Case 1: No Finish-Side Successor
In Figure 1, Task D is a successor to Task C using a Finish-to-Start (FS) relationship and is a predecessor to Task F using a Start-to-Start (SS) relationship.
Figure 1
Task D has both a predecessor and a successor activity, so it does not violate the “No Open Ends” rule. Accordingly, the P6 Global filters “Activities without Predecessors” and “Activities without Successors” return no results.
However, Task D’s only successor is linked from its start. No logic leaves Task D’s finish, so the finish behaves as if it were open-ended.
Increasing Task D’s Original Duration (OD) and recalculating the schedule gives these results:
OD from 10 to 12 days: Task D’s Total Float (TF) does not change.
OD of 17 to 22 days: Task D’s TF value decreases, but Task F’s start and finish dates do not change.
OD of 23 days or more: Task D becomes critical and finishes after 29-Nov-26. Task F and Finish Milestone G still show a finish of 29-Nov-26.
You can’t build a P6 filter that finds this condition because there are no options available to construct the specific query. Ƶümmer identifies this anomaly in Analysis Report #14, “Activities with No Finish Side Successor,” (Figure 2).
Figure 2
Case 2: No Start-Side Predecessor
In Figure 3, Task D is a successor to Task C using a Finish-to-Finish (FF) relationship with a 5-day lag and is a predecessor to Task F using a FS relationship.
Figure 3
As in Case 1, Task D has both a predecessor and a successor, so P6’s open-ends filters returns no results.
However, Task D’s only predecessor is linked to its finish. No logic enters Task D’s start, so the start behaves as if it were open-ended.
Increasing Task D’s OD and recalculating the schedule gives these results:
OD from 10 to 31 days: No dates or TF values change for Task D or any other activity.
OD of 32 to 41 days: Task D’s TF value decreases, but no other activity’s dates change.
OD of more than 42 days: Task D starts on the Data Date and becomes critical. Task F is affected; however, Start Milestone A and Tasks B and C keep their dates, and their TF value increases accordingly.
You can’t build a P6 filter that finds this condition because there are no options available to construct the specific query. Ƶümmer identifies this anomaly in Analysis Report #15, “Activities with No Start Side Predecessor” (Figure 4).
Figure 4
Conclusion
In a CPM network, logic should flow through every task like water through a pipe. During the forward pass, at least one relationship must carry logic into the start and out of the finish of each task. During the backward pass, at least one relationship must carry logic into the finish and out of the start of each task. Checking both conditions helps confirm—although it does not guarantee—that the CPM network conforms to industry best practice rules and guidelines.
Negative Total Float values are commonly interpreted as an indication that a Project is not meeting its completion requirements. This is often due to the presence of an imposed constraint such as “Finish-On-or-Before” or “Must Finish By” on a task, milestone or the Project in the CPM network. When Negative Total Float values occur, it typically signals the need for corrective action(s) to recover from any resulting delays or impacts.
Negative Total Float Values Without Constraints
While constraints are the usual cause of negative Total Float values, it is possible for negative Total Float values to occur even in their absence. This scenario can arise from the way calendars are assigned to different tasks and milestones within a schedule.
Illustrative Example
Figure 1
Consider the Project’s “Zum_NTFL” CPM network shown in Figure 1 above. For clarity, the Early Start, Early Finish, Late Finish and Calendar assignment columns are displayed. In addition, the Date Format is expanded to show the Time with AM/PM. Finally, the Data Date is set to Monday, June 1 at 8:00 AM.
Activity A1000 – “Milestone A” is a Start Milestone and is assigned to the PC – Standard 5-Day Work Week Calendar.
Activity A1010 – “Task B” is assigned to the PC – Standard 5-Day Work Week calendar and has an Original Duration of 2 Days, resulting in an Early Finish of Tuesday, June 2 at 5:00PM.
Activity – A1020 – “Task C” is assigned to the PC – Standard 7-Day Work Week calendar and has an Original Duration of 4 Days, resulting in an Early Finish of Saturday, June 6 at 5:00PM.
Activity A1030 – “Milestone D” is a Finish Milestone and is assigned to the PC – Standard 5-Day Work Week calendar.
The 7-Day and 5-Day Work Week calendars are configured so that the Detailed work hours/day setting include 8 Work hours per day from 08:00 thru 12:00 and from 01:00 thru 05:00.
Since “Milestone D” is assigned to the PC – Standard 5-Day Work Week calendar, the calendar’s setting does not allow for a Saturday finish. As a result, the Early Finish for “Milestone D” is Monday, June 8 at 08:00 AM. Note that the time is 08:00 AM (instead of 5:00PM) because that is the earliest available date/time in the PC – Standard 5-Day Work Week calendar.
During the Backward Pass, the Late Finish for “Milestone D” begins at latest available Finish Date based on the PC – Standard 5-Day Work Week calendar which is Friday, June 5 at 5:00 PM. Keep in mind that with respect to the PC – Standard 5-Day Work Week calendar, 08-Jun-26 08:00 AM and 05-Jun-26 05:00 PM are effectively the same point in time.
Since “Task C” is a direct predecessor to “Milestone D”, “Task C”’s Late Finish is also calculated to Friday, June 5 at 5:00PM. However, that date is 1 day earlier than its Early Finish of Saturday, June 6 at 5:00PM. Therefore, the Total Float value for “Task C” is -1 Day and the Backward Pass propagates this negative value through the remaining CPM network.
Accumulation of “False Negative” Total Float values
In complex CPM networks with numerous activities and multiple calendars, this effect can compound, resulting in what can be classified as “False Negative” Total Float values. These values do not necessarily reflect actual schedule problems but are rather a result of calendar misalignment.
This anomaly is also noted in the “Warnings” section of the P6 Schedule log text output file when a Finish Milestone has a different calendar than its predecessor activity (See Figure 2 below).
Figure 2
Solution
To resolve the issue illustrated above, one simple solution is to reassign “Milestone D” to the same 7-Day Work Week calendar used for “Task C”. Once this adjustment is made, recalculating the schedule will eliminate the negative Total Float value, restoring accurate Total Float values throughout the CPM network.
In a CPM network, a lag’s value should be less than the Original Duration of its predecessor and successor activity pair so that it doesn’t open a gap in the flow of logic. When a lag exceeds the predecessor’s or successor’s assigned Duration, a non-overlapping condition can occur.
Many schedule specifications prohibit using lags in place of activities. At first glance, only a Finish-to-Start relationship with a positive lag appears to break that rule (Case 2 below). On closer inspection, Cases 1, 3, and 4 break it too: any lag that opens a gap between the predecessor and successor activity pair has the same effect as the more familiar Case 2.
These gaps are easy to create and hard to spot. A non-overlapping lag can occur in four ways and are addressed in the Zümmer Analysis Selected Report(s) box shown in Figure 1 below:
Figure 1
Case 1: The Negative Lag is greater than the sum of the Predecessor’s Original Duration and the Successor’s Original Duration (Figure 2).
Figure 2
Suppose the Original Duration (OD) for Activities “A” and “B” are set to 5 Days each, with a Finish-To-Start (FS) relationship and a lag of -9 Days. This is an acceptable overlap, because the absolute value of the lag (9 Days) is less than the combined OD of “A” and “B” (10 Days).
Now suppose the OD of both activities are reduced to 2 Days. Unless the relationship changes, a non-overlapping condition occurs (Figure 2): the absolute value of the FS lag (9 Days) exceeds the combined OD of “A” and “B” (4 Days), leaving a 5-Day gap between them.
In P6, no filter can be constructed to check for this type of non-overlapping lag. Case 1 is the least common of the four, because most schedule specifications prohibit negative lags outright.
Zümmer Analysis Report #31 – “Negative Lag Greater Than Sum of Both Original Durations” flags this condition as “Neg Lag > Pred OD + Succ OD.” Figure 3 below lists each non-overlapping relationship as an individual pairing, showing the Activity Status and Original Duration of both the predecessor and successor, plus the relationship type and lag.
Figure 3
Case 2:A Positive Finish-To-Start lag is used between 2 Activities (Figure 4).
Figure 4
Suppose the Original Duration
(OD) for Activities “A” and “B” are set to 7 Days each and the relationship is
set to Finish-To-Start (FS) with a lag of -2 Days. This is overlapping since
the sum of the durations of “A” and “B” is 14 Days.
Now change the lag to +7 Days. A positive Finish-To-Start lag pushes “B” away from “A”, opening a 7-Day gap. This can be resolved by replacing the lag with an activity whose Original Duration equals the lag value.
In P6, no filter can be constructed to check for this type of non-overlapping lag. Case 2 is often used to force a successor’s start date, especially when the predecessor and successor are assigned to different calendars.
Zümmer Analysis Report #32 – “Activities Finish-To-Start Relationship with Positive Lag” flags this condition as “FS with Positive Lag.” Figure 5 below lists each non-overlapping relationship as an individual pairing, showing the Activity Status and Original Duration of both the predecessor and successor, plus the relationship type and lag.
Figure 5
Case 3:A Start-To-Start Lag is greater than the Predecessor’s Original Duration (Figure 6).
Figure 6
Suppose the Original Duration (OD) for Activities “A” and “B” are set to 15 Days each, with a Start-To-Start (SS) relationship and a lag of 8 Days. This is acceptable, because “A” and “B” overlap.
Now reduce the OD of “A” to 5 Days. Unless the relationship changes, a non-overlapping condition occurs: the SS lag (8 Days) exceeds the OD of “A” (5 Days), leaving a 3-Day gap between the two activities.
In P6, no Filter that can be
constructed to check for this type of Non-Overlapping Lag.
Zümmer Analysis Report #33 – “Start-To-Start Relationships & Lag Greater Than Predecessor’s Original Duration” flags this condition as “SS Lag > Predecessor OD.” Figure 7 below lists each non-overlapping relationship as an individual pairing, showing the Activity Status and Original Duration of both the predecessor and successor, plus the relationship type and lag.
Figure 7
Case 4:A Finish-To-Finish Lag is greater than the Successor’s Original Duration (Figure 8).
Figure 8
Suppose the Original Duration (OD) for Activities “A” and “B” are set to 15 Days each, with a Finish-To-Finish (FF) relationship and a lag of 8 Days. This is acceptable, because “A” and “B” overlap.
Now reduce the OD of “B” to 5 Days. Unless the relationship changes, a non-overlapping condition occurs: the FF lag (8 Days) exceeds the OD of “B” (5 Days), leaving a 3-Day gap between the two activities.
In P6, no Filter that can be
constructed to check for this type of Non-Overlapping Lag.
Zümmer Analysis Report #34 – “Finish-To-Finish Relationships & Lag Greater Than Successor’s Original Duration” flags this condition as “FF Lag > Successor OD.” Figure 9 below lists each non-overlapping relationship as an individual pairing, showing the Activity Status and Original Duration of both the predecessor and successor, plus the relationship type and lag.
Use Zümmer’s Total Float Distribution Curve to evaluate the condition of a CPM Network.
Overview
Analyzing and understanding the distribution of Total Float (TF) values across a CPM network is a simple but revealing health check. As a general rule, CPM networks with a more “Stressed” TF distribution are more sensitive to Project delays and claims than CPM networks with a more “Relaxed” TF distribution.
How to Read the Total Float Distribution Curve
Zümmer’s Total Float Distribution Curve report plots every task’s Total Float value allowing you to evaluate the condition of the CPM network at a glance:
X-axis — the Total Float value, in days.
Y-axis — Percentile of All Tasks: the percentage of tasks that have that Total Float value or less.
Example of a “Stressed” CPM Network
In the “Stressed” CPM Network example shown above, the 1,000 tasks span Total Float values from 0 to 200 days. Reading the curve:
At the 50th percentile, Total Float is about 28 days — half of all tasks have about 28 days of Total Float or less. (Red Arrows)
At the Midpoint of Total Float values (100 days Total Float) – about 82% of all tasks fall at or below the midpoint Total Float value. (Green Arrows)
More than 10% of tasks have zero Total Float and sit on the Critical Path (Yellow Arrow).
Example of a “Relaxed” CPM Network
In the “Relaxed” CPM Network example shown above, the 1,000 tasks span Total Float values from 0 to 200 days. Reading the curve:
At the 50th percentile, Total Float is about 108 days — half of all tasks have about 108 days of Total Float or less. (Red Arrows)
At the Midpoint of Total Float values (100 days) – about 40% of all tasks fall at or below the midpoint Total Float value. (Green Arrows)
Only about 5% of tasks have zero Total Float and sit on the Critical Path (Yellow Arrow).
Interpreting the Curves
All else being equal, Projects with a “stressed” distribution are more likely to have a greater potential for claims and experience delays than those with a “relaxed” distribution. A precise rule of thumb is debatable, but by observation:
Identifying Stressed CPM Networks — curves that are steep on the left side and flat on the right side. In Stressed CPM networks, the red arrows are well inside the green arrow boundary. Also, the percent of activities on the Critical Path is excessive. Typically, 10% or more is considered the high boundary threshold.
Identifying Relaxed CPM Networks — curves that rise smoothly from beginning to end. In Relaxed CPM networks, the green arrows are typically inside the red arrow boundary. Also, the percent of activities on the Critical Path is low. Typically, 5% or below is considered the low boundary threshold.
When to Take Action
A closer look at the schedule’s logic may be warranted when either Stressed or Relaxed conditions exists in the extreme.
Very stressed distributions may signal a “claims-oriented” schedule. Review the overall logic to find relationships that can be removed or revised, thereby increasing overall Total Float.
Very relaxed distributions may signal an insufficiently developed schedule. Review the overall logic to find relationships that can be added or revised, thereby decreasing overall Total Float.
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.
In addition, to make your decision-making process easier, you can download the entire Zümmer Manual here for free! (601 Pages, 46MB).
Some new Zümmer features include:
Improved Activity Finish History graphing:
Activity Status indicators on the Finish Date line graph.
Data Date line graph with data point value that indicates #Days to Finish.
Green shading between Data Date line & Finish Date line added for easier viewing.
Improved Activity Finish History Report.
2. Improved Activity Finish History Trending
Activity Status indicators on the Finish Date line graph.
Data Date line graph with data point value that indicates #Days to Finish.
Green shading between Data Date line & Finish Date line enhances forensic analysis.
Easier to read trendline.
Improved Activity Finish Trending Report.
Automatically outputs to Excel Spreadsheet.
3.Added Activity Logic History Module:
Track, print & analyze logic changes to any selected activity across multiple Project Updates.
4. Added Activity Cost History Module – Graphing:
Graphically plot Activity Resource Cost status across multiple Project Updates.
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.
Bad Form
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.
Better
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.
Conclusion
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.
