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.
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.
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.
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.
Think twice before using Finish-to-Finish relationships between tasks.
By definition, a Finish to finish (FF) relationship is:
A relationship in which the finish of a successor activity depends on the finish of its predecessor activity.
Unfortunately, as will be explained in the article, FF relationships can cause illogical and erroneous results in your CPM network without any warnings or error message. Too often FF relationships, especially when no lag is used between tasks, as shown in Figure 1, are used without consideration of the negative effects this may impose on a CPM network. Even seasoned Schedulers with decades of scheduling experience can easily fall into this trap considering this relationship as acceptable and reasonable and will fervently defend its use with a multitude of “real-world” examples.
To understand the issue, we must first remove any “real-world” justification from the argument by realizing that P6 does not care about your Activity Name. The forward & backward pass algorithm works exactly the same regardless of what Activity Name is typed in. Therefore, we must approach this issue from an abstract perspective. Any use of a “real-world” example will almost always cause anyone to justify its use and therefore perpetuate its mis-use.
The FF Trap – Issue 1 – What is the true successor?
Figure 1 – FF relationship between tasks.
In the Figure 1 above, the successor to Activity A is Activity B. P6 allows this relationships and this counts as a non-opened end. However, upon further inspection, assigning the finish of Activity B as a successor leaves much to be desired. What’s missing is understanding how the CPM network progresses. One should ask “What task continues along this path?” Assuming Activity B is the only successor to Activity A, then Activity A is missing a successor that is tied to its start. This falls in the “No Finish Side Successor” logic error category.
Zümmer Analysis Report # [14] – “Activities with No Finish Side Successor” (shown below in Figure 2) identifies each Activity that violates this anomaly.
Figure 2 – Zümmer Analysis Report [14]
The FF Trap – Issue 2 – What is the true predecessor?
In the Figure 1 above, the predecessor to Activity B is Activity A. P6 allows this relationships and this counts as a non-opened end. However, upon further inspection, assigning the finish of Activity B as a predecessor leaves much to be desired. What’s missing is understanding how Activity B is progressed by the CPM. One should ask “What task allows Activity B to start?” Assuming Activity A is the only predecessor to Activity B, then Activity B is missing a predecessor that is tied to the start of the Activity B. This falls in the “No Start Side Predecessor” logic error category.
Zümmer Analysis Report # [15] – “Activities with No Start Side Predecessor” (shown below in Figure 3) identifies each Activity that violates this anomaly.
Figure 3 – Zümmer Analysis Report [15]
The FF Trap – Issue 3 – Which activity has priority over controlling the start of the Activity 2?
Figure 4 – Which Activity controls the start of Activity 2?
In Figure 4 above, the predecessor to Activity 2 is Activity B with a Finish-to-Start (FS) relationship and the predecessor to Activity B is Activity A with a FF relationship. However, upon further consideration, you may ask if there is no lag between Activity A and Activity B, then which activity actually controls the start date of Activity 2? Without a lag between Activity A and Activity B, then both Activity A and Activity B equally control the start of Activity 2. In conclusion, in this case, the predecessors to Activity 2 is both Activity A and Activity B with a FS relationship. Therefore, the correct network logic to use is shown in Figure 5 below.
Figure 5 – Correcting the FF between task anomaly.
Zümmer Analysis Report # [35] – “Tasks with Finish-to-Finish Relationships and No Lag” (shown below in Figure 6) identifies each Activity that violates this anomaly.
Figure 6 – Zümmer Analysis Report [35]
The FF Trap – Issue 4 – Potential erroneous Early Start/Early Finish dates for Activity B.
In Figure 1 above, the FF usage may appear reasonable when considering Activity A and Activity B alone. However, considering other activities in the CPM network, the calculated Early Start, Early Finish date and consequently the Total Float values may be incorrect for Activity B. Even worse, P6 does not provide any warning messages, notice or explanation of this potential error.
Figure 7 – Incorrect Early Start for Activity B
In the Figure 7 above, note that the Original Duration for Activity A is greater than Activity B. In the case, when the CPM network is calculated, the Early Start for Activity B is no longer controlled by the Early Finish of Activity 1. The FF relationship shown is essentially pulls the start of Activity B away from its normal driving predecessor and behaves as if Activity B was assigned an “As Late As Possible” constraint. In other words, the driving predecessor to Activity B is defined by the finish of Activity A and the Early Start is defined the Early Finish of Activity B minus the Original Duration for Activity B.
Figure 8 – Incorrect Early Start for Activity B when Activity A OD is < Activity B OD.
In Figure 8 above, the same situation occurs when total when Activity B is less that Activity A, but the Original Durations between Activity 1 and Activity 3 is greater than Activity B. Again, P6 provides no error message or notice for this issue.
Figure 9 – A possible solution to resolve FF between Activities A and B.
The immediate solution to this issue may be to revise the logic (as shown in Figure 9 above) so that Activity B starts after Activity 1. However, this might not be the intent of the Scheduler to accurately model the start date for Activity B. For example, if the Original Duration for Activity A is much greater than Activity B, then the CPM network model in Figure 9 may not correctly convey the Schedule’s intent.
Figure 10 – Alternative Solution to Resolve FF between Activities A and B.
When the Original Duration for Activity A is much larger than Activity B an alternative solution is to break Activity A into 2 activities. In Figure 10 above, Activity A2 is added to the CPM network with an Original Duration with about the same Orginal Duration as Activity A1. The sum of the Original Durations of new Activities A1 and A2 is the same as the Original Duration of Activity A in Figure 9.
The FF Trap – Issue 5 – What about lags?
Figure 11 – FF with a lag between tasks.
The use of a lags in a CPM network is probably a discussion all to its own. However, with regard to FF relationships with a lag, special care should be considered prior to its usage. When a FF lag is inserted, as shown in Figure 11 above, the CPM network, at least declares that Activity B has priority over the start date of Activity 2. This solves the problem discussed in
Issue 3 above. However, even though a lag is inserted between Activity A and Activity B, this does not necessarily resolve the problems associated with Issue 4 above.
The FF Trap – Issue 6 – FF lag greater than Successor’s Original Duration
Figure 12 – FF lag greater than Successor’s OD.
In Figure 12 above, a FF lag is inserted between Activity A and Activity B. Unfortunately, the FF value is greater than the Original Duration (the successor) for Activity B. This usage causes an “non-overlapping” relationship condition. Issue 6, is one of four possible non-overlapping conditions.
Sadly, this relationship error is very easy to commit. For example, suppose Activity A and Activity B was originally added to the CPM network with Original Duration of 10 and the FF lag is set to 5. Here, the lag value of 5 is small enough so that both Activity A and Activity B overlap. This is an acceptable condition. However, suppose now that the Original Duration for Activity B is reduced to 4 Days. More often than not, these type of schedule changes are made without consideration of a lag value that was previously inserted. Now, with an Original Duration of 4 Days for Activity B, the FF lag of 5 Days results in a non-overlapping condition of 1 day.
Zümmer Analysis Report # [35] – “Finish-to-Finish Relationships & Lag Greater Than Successor’s Original Duration” (shown below in Figure 13) identifies each Activity that violates this anomaly.
Figure 13 – Zümmer Analysis Report [34].
The FF Trap – Issue 7 – When is it appropriate or best to use a FF relationship?
Figure 14 – Predecessor task -> Successor Finish Milestone.
After reading through the perils of FF usage, you may ask when is it appropriate or best to use FF in a CPM network? Fortunately, an excellent way to use FF relationships is when the successor activity type is a Finish Milestone (as shown in Figure 14 above). Since a Finish Milestone does not have a start component, using FF relationships here is an excellent choice. Although P6 does allow the use of FS between the finish of a task and a Finish Milestones, using a FF relationship keeps your relationship lines neat and tidy. Figure 15 below, the left panel shows the effects of using mixed relationship type when the successor is a Finish Milestones. In this case, it is much preferred is to consistently use a FF relationship. The right panel in Figure 15 below, illustrates the neat and tidy results when FF is used.
P6 is a versatile and powerful CPM networking tool, allowing 4 different relationship types (FS, FF, Start-to-Start (SS) and Start-to-Finish(SF)) with the ability to assign a lag value (including negative lag values). However, much care and consideration should be used when using any one of these relationship types, especially anything other than the typical Finish-to-Start relationship is used. The bottom line, here is to build a CPM network with very limited use anything other than the tried-and-true FS relationship. All other relationship types, should be used only in deliberate and clearly justifiable situations.
Finally, the converse to the FF Trap is the equally perilous SS Trap which is discussed in detail in “The Start-to-Start relationship Trap” article.
Nearly every P6 Export File I have ever received has a Global Calendar embedded in it.
Many construction project specifications state that Global Calendars and Global Activity Codes (Global Activity Codes will be discussed in a separate article) are not to be included in the Project Schedule. The reason is that the Owner or Agency wants to control the number of Global Calendars in their P6 CPM Network.
Imagine a large agency such as a State Department of Transportation that receives Project schedules from scores of Contractors. If the Global Calendars are not properly managed, the agency can easily wind up with literally hundreds of Global Calendars. Many of these Global Calendars may not be easily attributable to a source Project. Some may be overtly faulty, expired and inadvertently assigned to activities from a different Project.
The worse-case scenario occurs when an existing Global Calendar is possibly overwritten by an imported Global Calendar of the same name. Just think of how many Global Calendar are named “Standard 5 Day Calendar”
In general, Global Calendars are
intended to be used only for creating Project or Resource Calendars. Therefore,
Global Calendars should never be transferred from one party to another.
For those submitting Project
Schedules to other parties, make sure that Global Calendars are not included in
the export file (typically the .XER file). Submitting Global Calendars to other
parties not only populates other P6 Users with superfluous Global Calendars but
is bad form and must be avoided.
For those receiving Project
Schedule from other parties, make sure that the import file (typically the .XER
file) does not contain Global Calendar. Otherwise, before long, your Global
Calendar list will contain scores of unrecognized and unassigned Global
Calendars with the potential of invalidating your CPM network.
Sadly, of the countless number .XER/.XML files I have received over the past 15 years (or so), nearly ALL of them contain references to a Global Calendar.
The reality is that most P6 Users (who may not necessarily be a “Scheduler”) don’t even realize that they are sending Global Calendars. Similarly, many P6 Users are not even aware of that the problem exists. Even then, if you’re aware of the issue, you could still be sending Global Calendars and not know how or why they are mysteriously propagating into your Export Files. Keeping Projects Global Calendar free is not as easy as you may think.
Unfortunately, there’s no export
option that reads “Omit Global Calendar References”. Therefore, below, I have
outlined a Step-By-Step procedure that will help you root out Global Calendars
from your export files.
Step 1: Establish a naming
convention that clearly distinguishes Global Calendars from Project Calendars.
In the illustration below, “**GC-99” has been added as a prefix to all existing Global Calendars. To ensure all are unique, the Global Calendar sequence was numbered from “00” to “15”. From this point forward, it will be easy to spot whenever Global Calendars are used in a Project. In addition, any new Global Calendars that have been inadvertently imported from an unvetted file can be easily and quickly identified.
Step 2: Make Sure no Activities in the Project are assigned to a Global Calendar.
Now that all Global Calendars are
clearly defined, Open the Project and set the Filter ‘All Activities’. Next,
Group & Sort by Calendar then collapse to ‘Calendar Level 1’. The result
should appear like image below.
In the image above, it’s easy to see that Project activities
are assigned to Global Calendars “**GC-00” and “**GC-06”.
From this point, reassign the activities with Global
Calendars to Project Calendars.
Step 3: Make Sure all Project Calendars are not inheriting from a Global Calendars.
From the Enterprise Main Menu, select “Calendar”. The Calendar window appear as shown below displaying all the Project Calendars created for the Project.
For each Project Calendar listed, click the Modify command button to display the window shown below:
For “TS-01 – 5 Day WrkWk – Gen’l Construction w/Holidays (Thru 2018)”, the Project Calendar is inheriting from “**GC-13 – Standard 5 Day Workweek”. Revise the inheritance setting to <None>. Continue this process for all Project Calendars regardless of whether the Project Calendar is assigned to an activity or not.
Step 4: Make Sure the Default Calendar is not a Global Calendar.
Whenever a new Project is
created, P6 automatically assigns the Global Default Calendar as the assigned
Default Calendar for the Project. As shown below, the selected Project defaults
to a Global Calendar when a new activity is added to the Project. Even if all
activities are assigned to a Project Calendar, having the Default Calendar set
to a Global Calendar will cause P6 to embed the Global Calendar when an export
file is created.
To remove the Global Calendar as the Default Calendar, first Open the Project, then select a Project Calendar as the Default Calendar. When the Project is closed and the Project is highlighted in the Projects Tab, no Default Calendar will be shown in the textbox. To see the assigned Calendar, simply re-open the Project then return the Projects-Defaults Tab.
Step 5: If you are using Resources, make sure the are using a shared or Personal Resource Calendar.
All Resources are assigned a Calendar which can be viewed in the Details ->Profile selection window. When a new Resource is created from scratch, P6’s designated Default Project Global Calendar is automatically assigned as the Default Calendar for the Resource. In the illustration below, the Carpenter resource Calendar Profile is assigned to a Global Calendar.
Resources can either be assigned
to a Personal Calendar or be assigned to a previously created Shared Resource
Calendar.
To prevent a Global Calendar from making its way into the .XER/.XML file, all Resources that are assigned to the Project’s activities must be assigned to either a Shared Resource Calendar or a Personal Calendar. Furthermore, whether a Shared Resource or Personal Calendar is used, the assigned Calendar must not be inheriting from a Global Calendar (See Step 3 above).
Step 6: Use the VFR (Visual File Review) technique to verify no Global Calendar references are contained in the .XER File.
Checking an .XER for Global Calendars is easy. Simply open the file using a text editor such as Notepad then scroll down to the Calendar Table (%T) section as shown below:
Below that line, look for a Record line starting with (%R). Reading to the right, the 7th field, which displays the record value for Field Name (%F) “clndr_type” is displayed. The three possible Record values for the Field “clndr_type” (Calendar Type) is:
CA_Base: Identifying a Global Calendar;
CA_Project: Identifying a Project
Calendar;
CA_Rsrc: Identifying a Resource Calendar.
If “CA_Base” exists as a Calendar Type, then a Global Calendar exists for the Project contained in the .XER File. In this case, return to P6, then reopen the Project, then go through Step 1 through 5 until you find offending Global Calendar assignment. Although, I don’t have an .XML example, the same approach applies.
Keeping “Lean & Mean” Global
Calendar free Projects helps stop the proliferation of redundant and
superfluous Global Calendars.
If you find this article useful,
I encourage you to pass it along to your P6 scheduling colleagues.
When it comes to adding logic
relationships in P6, things can get out-of-hand in no time. During the CPM
network development phase, logic relationships are constantly added, deleted
and revised. At the completion of the process the CPM network diagram can end
up looking like a messy bowl of spaghetti.
Good scheduling practice calls for minimizing, as reasonably as possible, the amount of logic relationships in the CPM network. Cluttered CPM networks can add confusion, promote faulty logic and increase errors especially when trying to trace logic paths.
Before diving further into this topic, and for the purposes of this discussion, we must first define our terms and the difference between “Redundant Relationships” and “Duplicate Relationships”.
A Redundant Relationship is defined as: an additional logic relationship between 2 activities that are not directly related to each other.
In the example below, the FS relationship between Activity B (B) and Activity H (H) is redundant because an existing inferred relationship between these 2 activities already exists through B->C->D->E->F->G->H. Since B and F are not directly related, then the relationship B->F is said to be “Redundant” since intermediate activities exists between each activity which are along the same logic path.
Since the relationship B->H is redundant, then this relationship can be safely deleted and will not affect any dates or Total Float values of any activity within the CPM network. Redundant relationships are easily detectable when a logic path is neatly grouped so that activities of the same logic path are sorted by start date. In the example below, activities B thru G are group in the same logic path and are sorted by Start date. The 3 redundant relationships are clearly shown (B->H; C-> E; and E->G) by the dotted relationship lines and therefore can be safely deleted.
Even though a redundant relationship exists, it doesn’t necessarily mean that the relationship should be deleted. A Scheduler may decide to intentionally retain a redundant relationship in the CPM Network. For example, the redundant relationship may represent a secondary “fallback” relationship in case the current driving relationship is not sustainable.
For example, in the illustration above, suppose the current driving predecessor (D) to Activity E is no longer valid. Then, by removing the relationship, D->E, then the new driving predecessor to E will be C. If the redundant relationship, C->E had been previously removed, then when the relationship D->E is removed, E will revert back to the Data Date when the schedule is recalculated.
For this reason, using redundant relationship removal algorithms is generally not recommended. Furthermore, and unfortunately, when it comes to P6, all relationships (other than the relationship type) are the same. There is no direct way to differentiate “soft” relationships from “hard” relationships; or “primary” relationships from “secondary” relationships; or “physical” relationships from “crew” relationships.
Redundant relationship removal algorithms generally remove relationships regardless of their priority or classification. Therefore, the recommended method for removal of relationships is by individual consideration and inspection.
A Duplicate Relationship is defined as: an additional logic relationship between 2 activities that are directly
related to each other.
Duplicate relationships can be
classified into 2 types.
In the illustration above, the first
type (Type 1) of Duplicate Relationship occurs when a SS/FF relationship pair is
used. Typically, a lag value (typically greater than 0) is
included in both relationship. This relationship technique is often used in
summary level type schedules where the activity detail is not totally defined. Since
the preferred technique in CPM networks is to allow only 1 relationship between
any 2 activities, this usage is not recommended for detailed or production level
schedules.
The second type (Type 2) of
Duplicate Relationship occurs when the relationship pair is not of the SS/FF
type. These duplicate pairs often occur when the “Link Relationship” option is
inadvertently used a second time (or more) spanning activities that are already
related. In most cases, the non-driving relationship is the relationship that
should be deleted. Therefore, for K->L, the FF duplicate relationship can be
safely deleted.
A subset of the Type 2 Duplicate Relationship is the “Multiple Instances” variety where more than 2 Duplicate Relationships exist between 2 activities. An example of this, as shown below, displays the relationships between M->N where every possible logic relationship exists between the 2 activities.
In the Successors relationship
window above, since the Driving relationship is FS, then all other listed
relationships can be safely deleted.
Zümmer’s Analysis Report #39 – “Duplicate Logic Relationships” shown below, lists all duplicate logic relationships in the selected Project.
This report groups duplicate logic
relationships separated by a heavy horizontal line. In the example above, the
duplicate logic relationship between M->N displays the Type 2 variety with all
4 assigned relationships. For this condition, the FF, SF and SS relationships
can be safely deleted.
The next group, between K->L,
displays the Type 2 variety with the FF/FS pair. For this condition, the FF
relationship can be safely deleted.
The last group, between I->J, displays the Type 1 variety with the SS/FF pair. Here, the I->J relationship contains a lag of 5 days for both SS and FF relationships. If Activities I & J are part of a detail production level schedule, then breaking down the scope into more detailed activities may be necessary to eliminate the duplicate logic condition.
The Filter option is probably the Scheduler’s most powerful
tool in P6. The Filter option allows the Scheduler to display only specific
activities based on the Filter criteria. There are a vast amount of options
that go beyond the scope of this article.
However, in this article, we will explore a not-well known or understood feature I’ll describe as “Multi-Leveling”. In other words, you can implement the multi-level filter technique that allows for multiple filter criteria to be combined into a single Filter.
In the sample Project shown below, “Thyme Street Bridge
Construction” consists of the construction 3 Piers comprised of Piles, Footers,
Columns and Caps. The Project is planned with 3 crews: a) a Pile Driving Crew;
B) a Footer Construction Crew; and C) a Carpenter Crew responsible for building
the Columns and Caps.
In this scenario, a reasonable CPM model for this Project would appear as shown below:
Now suppose we need to display
(or Filter) only the Cap construction for Piers 1 and Piers 3. Since the sample
set above is small, there are multiple options to accomplish this. However, for
the purposes of illustration, the most common solution would be to create 2
Filters. One filter to select only the Cap Construction, then another to select
Piers 1 and Piers 2. Once the 2 independent Filters are defined, the option to
“Show activities that match” is set to “All selected filters”.
The common solution approach
consists of:
Create a Filter to Select only Cap Construction as shown below:
The Filter shown above uses the “(All of the following)” option to select only activities containing the word “Cap”.
Create a Filter to Select Pier 1 or Pier 3 Construction as shown below:
The Filter shown above uses the “(Any of the following)” option to select only activities containing the word “Pier 1” or “Pier 3”.
Under the “Show activities that match” text, select the “All selected filters” option, then select both Filters created above as shown below:
The results of the 2 Filter selection criteria are correctly shown below:
The above solution is correct and operative, however, with the use of Multi-level Filtering, a better and more efficient solution can be constructed by combining both Filters into one Filter Criteria as shown below.
Create the first Filter criteria exactly as in Step 1 above as shown below:
Next, Include the next criteria similar to Step 2 above:
Add a third line using the “(Any of the following)” option similar to Step 2 above.
Add a fourth line, then enter the criteria “Where Activity Name contains Pier 1”. Make sure that Line 3 as shown below contains the “-“ symbol on the left indicating a second level is defined for the filter criteria. If the “-“ symbol is not shown, then click on the “Shift Right” arrow to create the second level. Notice also that the second “-“ symbol is indented indicating the second level criteria.
Add the fifth and final line, then enter the
criteria “Where Activity Name contains Pier 3”. Make sure line 5 begins with
“Or”. When done, select OK.
The results of the 1 Filter
selection criteria are correctly shown below:
This solution is more efficient since only 1 Filter used
eliminating the need to specify the “Show activities that match” option.
In conclusion, this simple example shows that the Filter option is more robust than what may initially appear. If necessary, additional levels can be added for more complicated Filters. The best way to improve your proficiency with Filters is to experiment with known results thereby better understanding its structure and behavior.
Stop the Proliferation of Global Calendars – a Step-by-Step Guide
Many construction project
specifications state that Global Calendars and Global Activity Codes (Global
Activity Codes will be discussed in a separate article) are not to be included
in the Project Schedule. The reason is that the Owner or Agency wants to control
the number of Global Calendars in their P6 Schedule Network.
Imagine a large agency such as a State Department of Transportation that receives Project schedules from scores of Contractors. If the Global Calendars are not properly managed, the Department can easily wind up with literally hundreds of Global Calendars of which many may not be easily attributable to a source Project or Contractor. Also, imported Global Calendars probably do not have a typical convention structure or time configuration which may inadvertently be used as the source of another Project Calendar. Additionally, existing Global Calendars could be overwritten if Global Calendars are imported with the same Calendar name.
In general, Global Calendars are
intended to be used only for creating Project or Resource Calendars. Therefore,
Global Calendars should never be transferred from one party to another.
For those submitting Project
Schedules to other parties, the submitter should make sure that Global
Calendars are not included in the export file (typically the .XER file). Submitting
Global Calendars to other parties not only populates other P6 Users with
superfluous Global Calendars but is bad form and should be avoided.
For those who receive Project Schedule from other parties, the recipient should make sure that the import file (typically the .XER file) does not contain Global Calendar. Otherwise, before long, the recipient’s Global Calendar list will contain scores of unrecognized, duplicate and unassigned Global Calendars.
At this point, you may consider attempting to purge and delete unused Global Calendars. However, this task can be more difficult than what may appear at first.
The following step-by-step procedure provides a guideline for cleaning up the Global Calendars List.
1. Create a Global Calendar naming convention that clearly distinguishes your Global Calendars from all other Global Calendars.
In the illustration below, the 8 highlighted Global Calendars names are preceded by a “*” then coded by “GC” prefix and a unique 2 digit number.
The “*” prefix helps to make sure
that when sorting by Calendar Name, the Global Calendars to keep are sorted to
the top of the grouping. The “GC” prefix identifies the Calendar as a Global
Calendar.
Using this type of convention allows P6 Users to easily spot authentic Global Calendar usage within a P6 Project and to identify those Global Calendars that are candidates for deletion. In addition, clearly identified Global Calendars facilitates stepping through the remaining checks & procedures.
2. Create a Global Calendar naming convention that clearly distinguishes other Global Calendars, from Project and Resource Calendars. These Global Calendars are candidates for deletion.
In the illustration below, note that the other listed Global Calendar names are preceded by a “GC” then coded with a unique 2 digit number and continue with a Calendar Name.
3. Attempt to remove all Global Calendars that are candidates for deletion.
Starting with the first Global
Calendar candidate for deletion, click on the Delete button shown above.
Case 1: Confirmation with “Are you sure…” window.
If the confirmation window
appears above and you are sure the Global Calendar can be deleted, the select “Yes”
and proceed to the next Global Calendar candidate for deletion.
Case 2: Error Message appears – Calendar [Calendar Name] cannot be deleted because it is used by activities in other projects.
If the error message window above
appears above, then click OK. Proceed through the next steps to be able to delete
the selected Global Calendar.
Click on the Used By… command button to display the Projects and/or Resources that are using the selected Global Calendar.
For each listed Project ID, open
the Project ID, then filter the Project to display all activities.
If the Project ID is not listed
in the EPS nodes, then the Project ID is embedded as Baseline in one of the
Projects residing at the EPS Level. This may be a time consuming effort is the
EPS Level Project ID is not immediately known. Once found, restore the Project
ID, then follow the Steps above to remove Global Calendars embedded in a
Baseline Project.
Next, Group and Sort the activity
list by Calendar with the Indent Checkbox selected as shown below.
Next, collapse the list so that all the activities are not shown as shown below:
Collapse the activity list so that only the Groups appear. In the illustration below, the activities are collapsed. Note that Project Activity ST03 – 6 Day Standard Workweek, is indented under “*GC-06 – 6 Day Standard – no Holidays”.
If a Calendar Level 2 exists,
then the Project contains Project Calendars that are inheriting from Global
Calendars. Follow Step 5 to change the Inherited Global Calendar setting to
<none>.
Continue assigning re-activities
from a Global Calendar to a Project Calendar. If a Project Calendar does not
exist for the activity, then create a new Project Calendar from a Global
Calendar (making sure that inheritance is set to <none>. Complete this
process until all activities are assigned to a Project Calendar.
Next Group by Resource, then
follow Step 7 to assign Resource Calendar to the Resources used in the Project.
Complete this process until all activities are assigned to Resources that are
assigned to a Resource Calendar.
Finally, close the Project then
delete the unwanted Global Calendar. Continue this process until all unwanted
Global Calendar candidates are deleted. The remaining Global Calendars are
valid and should remaining in the Project Network.
4. Unassign all remaining valid Global Calendars.
Next, for each valid Global
Calendar attempt to the delete the specific Calendar. Since the Default Global
Calendar cannot be deleted, temporarily assign another Global Calendar as the
Default. If the confirmation textbox appears to delete the Calendar, select No,
then continue to the next Global Calendar.
If P6 cannot delete the selected
Global Calendar, then follow the instructions found in Step 3, Case 2 above.
Continue this process until all
valid Global Calendars are not assigned to P6 Projects.
The next steps below ensure that exported Project files do not contain any Global Calendars. Even though Projects do not contain activities or resources assigned to Global Calendars, you can still wind up with Global Calendars contained in the export Project file.
5. Ensure that no Project Calendars are inheriting from Global Calendars.
When a Project Calendar is created from a Global Calendar,
the Project Calendar automatically inherits its properties from the selected
Global Calendar. In the sample below, the Project Calendar “PC-01 – 7 Day WrkWk
– No Holidays” is inheriting from the Global Calendar “*GC-01 – 7 Day WrkWk –
No Holidays ”.
Left this way, the inherited Global Calendar is
automatically brought in when an .XER file is created.
For each Project Calendar ensure that the Project Calendars are not inheriting from a Global Calendar by selecting the Modify… command button as shown below.
Next scroll through the Global Calendar list, then select <none> from the pull-down menu as shown below.
To prevent a Global Calendar from making its way into the .XER as a result of Inheritance, set all Project Calendar’s inheritance to “<none>”. In the illustration above, the pull-down menu is expanded to display the “<none>” option from the list of Global Calendars.
6. Ensure that Projects do not Default to a Global Calendar.
Every Project has an assigned Default Calendar. The setting for the Default Calendar for a Project can be seen in the Project’s Default Page in the Project’s Detail window as shown below.
When a new Project is created from scratch, P6’s designated
Default Project Calendar is automatically assigned as the Default Calendar for
the Project. When a Project has a Global Calendar as the Default Project
Calendar, then that Global Calendar will be saved in the exported .XER file.
To prevent a Global Calendar from making its way into the .XER as a result of Default Calendar settings, first, open the Project, then select a Project Calendar as the Default Calendar.
7. Ensure that Resources assigned to activities do not have a Calendar Profile referencing to a Global Calendar.
All Resources are assigned a Calendar which can be viewed in the Details ->Profile selection window. When a new Resource is created from scratch, P6’s designated Default Project Global Calendar is automatically assigned as the Default Calendar for the Resource. In the illustration below, the Carpenter resource Calendar Profile is assigned to a Global Calendar.
Resources can either be assigned
to a Personal Calendar or be assigned to a previously created Shared Resource
Calendar.
To prevent a Global Calendar from making its way into the .XER file, all Resources that are assigned to the Project’s activities must be assigned to either a Shared Resource Calendar or a Personal Calendar. Furthermore, whether a Shared Resource or Personal Calendar is used, the assigned Calendar must not be inheriting from a Global Calendar (See Step 5 above).
8. Final QA/QC .XER visual inspection.
Checking an .XER for Global Calendars is easy. Simply open the file using a text editor such as Notepad then scroll down to the Calendar Table (%T) section as shown below:
Below that line, now look for a Record line starting with (%R). Reading to the right, the 7th field, which displays the Record value for field name (%F) “clndr_type” is displayed. The three possible Record values for the Field “clndr_type” (Calendar Type) is:
CA_Base:
Identifying a Global Calendar;
CA_Project:
Identifying a Project Calendar;
CA_Rsrc:
Identifying a Resource Calendar.
If “CA_Base” exists as a Calendar Type, then a Global
Calendar exist for the Project contained in the .XER File.
If you submit schedules in .XER
format and “CA_Base” is contained in the .XER file, then go back and follow the
steps above to remove any reference to a Global Calendar.
If you receive schedules in .XER format and “CA_Base” is contained in the .XER file, then return the .XER file to the submitting party for correction.
Keeping a “Lean & Mean” Global Calendar list helps stop the proliferation of redundant and superfluous Global Calendars.
