Tips, Trap, Tricks – The Official Site for Zümmer – CPM Schedule Analysis & Comparison

The Finish-to-Finish Relationship Trap

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.

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.

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.

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.

Figure 15 – Keeping relationship lines neat & tidy.

The FF Trap – Summary

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.

How to Guarantee Delivery of a Global Calendar Free P6 Export File

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.

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

Redundant vs Duplicate Relationships

Defining Relationship Terms.

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.

Multi-Level Filtering

Take your Filtering skills to the next level…

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.

Keep Global Calendars to Yourself!

Stop the Proliferation of Global Calendars – a Step-by-Step Guide

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.

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

The Partial Day Effect

Finding and eliminating “Partial Days” is an important part of a Scheduler’s QA/QC routine.

A deeper look into the Partial Day Effect

Since most CPM scheduling performed in the construction industry measures time to the nearest day, calculating overall project durations by summing tasks containing units of measure less than a whole day should be strictly avoided. Keep in mind that schedulers are not timekeepers and they should resist the temptation to calculate the overall project time using durations more precise that a whole day. Furthermore, since schedulers typically record actual dates to the nearest day, it doesn’t make sense to calculate future dates to anything more precise than whole days.

The “Partial Day” (or Fractional Day) Effect is defined as:

Tasks that do not start at the beginning of the day.
Tasks that do not finish at the end of the day.
Tasks that have non-integer day value for their Original or Remaining Duration.
Tasks that have non-integer day value for their Total Float or Free Float.
Lags that have non-integer day values.

The Partial Day Effect manifests itself when upon browsing the calculated dates in a CPM schedule; you or someone else notice activities are starting on the same day as its predecessor’s finish date. This can cause confusion especially with experienced CPM users who are accustomed to seeing predecessor finish dates completing on the day before (or just before) the successor’s start date.

In Figure 1 below, the User Preferences Time option is set to “Do not show time”. Note that the Early Finish date for Activity “A1040 – Activity C1” is 09-Jun-16 which is the same date for the Early Start of its successor, Activity “A1050 – Activity F”. In addition, Activity “A1060 – Activity C2” has the same Original and Remaining Duration as Activity C1 yet is not on the Critical Path. Furthermore, the layout is grouped by Total Float; however there are 2 separate groups for the same Total Float value of 0. How can this be?

In Figure 2 below, the User Preferences Time option is now set to “24 hour (13:30)” Under these settings, the Partial Day Effect is revealed by observing the Datetime format of Start and Finish dates.

The Partial Day Effect in this situation was caused due to how each activity was statused.

A1020 was updated by assigning a Duration Percent Complete of 35%.
A1060 was updated by assigning a Remaining Duration (RD) of 16 days.

P6 calculates the RD for A1020 as 25*(1-.35) or 16.25 Days. The .25 remainder (or 2 hours) is reflected in the Finish date as 09-Jun-16 10:00 (10AM). Meanwhile, A1060 displays the same RD as A1020; however, the Finish date is reflected as 08-Jun-16 at 17:00 (5PM). Furthermore, A1060 is not on the Critical Path even though the Total Float (TF) value is displayed as 0 (the Duration Format Decimal value for the Day Unit of Time is set to 0).

The Partial Day Effect is also caused by how P6 stores dates and durations. In the typical P6 Duration fields such as Original Duration and Remaining Duration the default entry mode is to display durations in days. However, the actual duration value stored in the P6 database is in Hours. In the Figure 3 below, the activities in Figures 1 and 2 are shown with their native field names and values for their Original Duration (Target_drtn_hr_cnt); Remaining Duration (Remain_drtn_hr_cnt); Total Float (Total_float_hr_cnt); and Free Float (Free_flt_drtn_hr_cnt).

The conversion occurs as a result of the Calendar setting value entered under the Hours/Day textbox in the Hours per Time Period window as shown in Figure 4 below.

Since the Work-Hours per day entry is “8” in Hours/Day, P6 automatically performs the “on-the-fly” mathematical conversion as values are entered. Therefore, for Activity 1020, the Original Duration entry of 40 is natively stored as 40*8 or 320 in the Task table’s “Target_drtn_hr_cnt” field. Similarly, the Remaining Duration, calculated as 35% Complete, is stored as 25*(1-.35)*8 or 130 in the Task table’s “Remain_drtn_hr_cnt” field.

Storing data in hours, instead of days often causes the Partial Day Effect when “mixed” calendars are used.

Mixing Calendars in a CPM Network

Typically, schedulers define their calendars to model whole days consistent with typical construction work environments in their area. For example, a typical calendar structure consists of a work-day that starts at 8:00AM, breaks for lunch from 12 Noon to 1:00PM and ends at 5:00PM for a total work-day of 8 Hours/Day. Based on these parameters, a typical P6 5-Day Work-Week Global or Project Calendar would have the following configuration in Figure 5 below.

6-Day Work-Week and 7-Day Work-Week would follow the same configuration but with the added additional Nonwork days accordingly.

Often, this convention above is violated when for example; a 24 Hour Calendar is used for concrete curing activities or some other type of “round-the-clock” activity. For this reason, I strongly discourage the use of 24-Hour calendar under any circumstance. For these types of activities, a 7-Day Work Week Calendar based on an 8 Hour per day and no holidays is the best option and works just as well. Many articles “for instructional purposes” use a 24-Hour Calendar that is assigned to a concrete curing activity or other “round-the-clock” activity. This option should be avoided in real-time construction activities since it is problematic and is often the root cause of Partial Days.

In the Figure 6 below, two “7-Day Cure” activities are used between a concrete pour activity and a concrete form activity. Activity ST8420 is assigned to a 7-Day Calendar using an 8 Hour per day format. Activity ST78430 is assigned to a 7-Day Calendar using a 24 Hour per day format. Activity ST68920 and ST68180 are both assigned to a 5-Day “Field” Work-Day Calendar using an 8 Hour per day format. The activities below are grouped by Total Float value. Upon calculating the schedule, both Cure activities finish on the same day, however, they both calculate a different Total Float value.

The activity on the 7-Day/8Hr calendar correctly calculates the starting and finish date while the activity on the 7-Day/24Hr calendar starts on the same day as the Pour Footing activity (18-Oct-19). Also, the overall duration is shown as 7 Days but based on the displayed Start and Finish date equates to 8 Days.

In addition, there is an apparent discrepancy in the Free Float values. Since 25-Oct-19 falls on a Friday, the Cure activity on the 7-Day/8Hr Calendar correctly calculates the Free Float as 2 Days since the successor, Activity ST6810 start on Monday, 28-Oct-19. The Free Float on the 7-Day/24Hr Calendar incorrectly calculates the Free Float as 3 Days as shown below in Figure 6.

When the Time option is set to 24 Hours, the following values appear in Figure 7 below.

Note that the 24 Hour time setting reveals additional information to clear up the confusion. Note that the start time for Activity ST84730 is 17:00 (5:00PM). Since this activity is on a 24 Hour calendar, it starts immediately after its predecessor’s finish date. Activity ST78420 and ST87430 both correctly finish at the same time.

When the Duration value option is changed to 2 decimal places, the Original Duration, Remaining Duration, Total Float and Free Float reveal the actual calculated Duration values in Figure 8 below.

Note that the Total Float and Free Float values for Activity ST78430 are displayed as 2.63. This calculation is derived from the difference between the Late Finish and Early Finish. Since the Late Finish is 28-Oct-19 at 08:00 and the Early Finish is 25-Oct-19 at 17:00, the difference is 63 Hours/24 Hours per Day or 2.63 Days (rounded to the nearest hundredth) as a direct result of using a 7-Day/24Hr Calendar.

Since calculating Project durations to the nearest whole day is preferred, the use of a 7-Day/24Hr Calendar is a root cause of the Partial Day Effect and therefore should be avoided. The Duration values compound when successor activities are later in the CPM network. This is because Total Float values are calculated based on the activity’s assigned Calendar.

Generating Partial Day Durations

There are many ways to generate Partial Day durations. Of these include:

Entering a Percent Complete value for an activity assigned with “Duration Percent Complete”. For example, if an activity has an Original Duration of 3 days and a Duration Percent Complete is assigned 50%, then the activity will start at 8:00AM then having 1.5 Days remaining will complete at Noon on the second Day.
Not assigning a whole Day value to a Remaining Duration. For example, if 1.5 Days is assigned as the Remaining Duration, then the Finish Date will complete at Noon.
An activity has a Calendar assignment that is not consistent with a typical hour per day format.
Assigning non-standard Calendars then using lags between activities with mixed format calendars.

However Partial Days are generated, they usually have a cascading effect through the CPM network that can make resolving this issue a difficult and painful task. Suppose for example, the first activity of a long CPM network path completes at 2:00PM. Then its next driving successor activity will start at 2:00PM on the same day and end at 2:00PM on its last day. This behavior will continue to cascade throughout the CPM network until there are no driving successors.

Determining if your CPM network contains Partial Days is easy! Simply;

Go to the User Settings and select the option to turn on time as shown in Figure 9 below.
Then, set Durations to display values to either 1 or 2 Decimal places shown in Figure 10 above.

Once this is done, you can browse the activities Start and Finish Dates to detect activities not starting at 8:00AM or not ending at 17:00PM.

Zümmer Analysis Reports

Zümmer contains the following reports to help resolve Partial Days (See also Figure 11 below):

Analysis Report #26 – “Activities with Partial Day Durations”
Analysis Report #27 – “Relationships with Partial Lag”
Analysis Report – “Not Completed Tasks with Partial Original or Remaining Durations”
Analysis Report – “In-Progress Tasks with Partial Remaining Duration”

Zümmer Analysis Report #26 – “Activities with Partial Day Durations” (Figure 12 below) is a comprehensive report listing any activity containing a Partial duration in the Original Duration, Remaining Duration, Free Float or Total Float values. The report sorts by Activity ID and lists the Activity Status, Activity ID, Activity Name, Partial Original Duration, Partial Remaining Duration, Partial Total Float and Partial Free Float values.

Zümmer Analysis Report #27 – “Relationships with Partial Lag” (Figure 13 below) is a comprehensive report listing any Partial Lags.

Partial lags have a most insidious impact towards generating Partial Days. Changing the predecessor or successor activity to a standard Calendar does not necessarily guarantee that the lag will change in kind. Even in a moderately sized CPM network, finding these offending lags are very difficult using P6 alone.

Zümmer Analysis Report – “Not Completed Tasks with Partial Original or Remaining Durations” (Figure 14 below) is a subset of Analysis Report #26 displayed above.

Not Completed Tasks with partial Original or Remaining durations have a higher priority with regards to resolving Partial Days because they tend to produce a cascading effect to successor activities starting or ending in the middle of the day. Once these activities are normalized, i.e. adjusted to containing whole day values, successor activities in general will ‘fall in line’ starting at the beginning of the day and ending at the end of the day.

Zümmer Analysis Report – “In Progress Activities with Partial Durations” (Figure 15 below) is a subset of Analysis Report #26 displayed above.

In-progress tasks with partial Remaining Durations also have a higher priority with regards to resolving because they tend to produce a cascading effect to successor activities starting or ending in the middle of the day. Once these activities are normalized, i.e. adjusted to containing whole day values, successor activities in general will ‘fall in line’ starting at the beginning of the day and ending at the end of the day.

Conclusion

A few tips to avoid Partial Days in the first place:

When performing a schedule update, turn on time to ensure calculated results start at 8:00AM and end at 5:00PM (or at your typical Start and Finish times).
When performing a schedule update, set the Duration decimal to 1 (or 2) to view duration values in tenths.
When declaring the Data Date, always set time on and set the Data Date time to include your typical Start time.
When assigning start constraints, turn on time and set the constraint to include your typical Start time.
When assigning finish constraints, turn on time and set the constraint to include your typical Finish time.
When setting “Must Finish By” constraints for the Project, turn on time and set the date to include your typical Finish time.
Use consistent “Hours per Day” configured Calendars especially when a lag value is assigned.
Update in-progress activities based on Remaining Duration in whole days or;
Update in-progress activities based on a completion date to include your typical Finish time.
For consistency, when actualizing start dates, save Actual Start dates to include your typical Start time.
For consistency, when actualizing finish dates, save Actual Finish dates to include your typical Finish time.
If someone asks you to do an analysis or ‘What-if’ the work is accelerated from an 8 Hour day to a 10 Hour day, suggest doing the analysis on a 6 Day Work-Week instead of a 5 Day Work-Week. The difference in calculations is between a 50 Hour week and a 48 Hour week which for scheduling purposed should be acceptable.

Keeping a neat, tidy and “wholesome” CPM network with no Partial Days is an important part of a Scheduler’s QA/QC routine.

Know your Calendar’s Expiration Date

Years ago, while preparing a schedule for what was then a 2-year project, I prepared a “5-Day Workweek – w/Holidays” Project Calendar 1 year beyond the original completion date. At the time, I expected a 1 year cushion would be more than enough to cover potential changes. However, as the project progressed, changes accumulated and the completion date eventually moved beyond the 1 year cushion I had originally created.

Unfortunately, I didn’t realize the error until an activity’s early finish date, set to a 5-Day Calendar with Holidays, coincidentally calculated to July 4. (oops!)

As a reminder, I now include the expiration date as part of the Calendar Name.

In the illustration above, the Project Calendar Names above are now labeled as “5-Day Workweek – w/Holidays thru 2020” and “6-Day Workweek – w/Holidays thru 2020” . Since the 7-Day Calendar contains no holidays, an expiration date is not necessary.

Project Naming Convention & EPS Structure

How to organize your EPS and Project ID’s.

OK, call me a “neat freak” but after years of working with P5/P6, I eventually settled in on an EPS Structure and Project naming convention that works for me. Of course, I’m sharing my personal procedure, if you have other preferences, feel free to incorporate them.

In the illustration above, the Top Node is the Project. I have other Nodes above such as Region/State and Company.

Below the Project Node, my subset includes:

A Node to contain the latest or “Current” Update. This Node usually contains only 1 Update.
A Node for Previous Updates. For very long Projects, I occasionally include Nodes grouped by Year so that there is no more than 12 Updates in each Node.
A Node for the Baseline Project Schedule. If there are multiple Baseline Project Schedules, I’ll create a separate Baseline Node for previous Project Baselines.
When necessary, I’ll include Project Node subsets for “What-if Studies”, “TIA’s”, “Sandbox”, etc.

For Project ID’s and Project Name, my naming convention is in the format: “PPP-BL#-UP## – Project Name – Update ## – DD dd-Mon-yy” where:

PPP: is a 2 or 3 character code that is unique to each Project.
BL#: References the source Baseline Project. i.e., the Baseline Project that the current Update was derived from. Unfortunately, the reality is that “re-baselines” can occur especially on multi-year projects. In the example below, if a re-baseline situation occurs, that schedule will be designated as “MST-BL2” all future Updates will be prefixed by “MST-BL2-UP##.
UP##: Represents the Update Number which increments by 1 from beginning to the end of the Project. The Update Number ## does not reset.
The Project Name references, the Project Name, Update Number and the Data Date (DD).

Note that Project Updates are NOT embedded as “Maintained Baselines”. When it’s necessary to perform baseline variance analysis, I’ll select the baselines from the Updates or Baselines node, then “assign” the appropriate schedules as “Project”, “Primary”, “Secondary” or “Tertiary”, then “Restore” when the variance analysis is complete.

Streamlining the Printing Process with Adobe Acrobat

Since Zümmer is a “report intensive application”, printing using Adobe Acrobat is an excellent way to process all Zümmer reports. However, the default Printing Preferences may slow down the process especially when printing multiple reports.

Changing the settings as noted below will vastly improve your experience when using Zümmer.

The instructions below work for Adobe Acrobat 9 Standard Version and Microsoft Windows 10. The procedure may vary with other Versions.

1) Create a New Folder on your desktop named Adobe PDF Output. (Fig. 1)

2) Click on the Windows Start button and select Devices and Printers.

3) Right-Click on the Printer Icon used for Adobe Acrobat. (Fig. 2)

a. Set as the Default Printer. A green check-mark appears on the bottom-left corner of the Icon.

4) Right-Click again and select Printing Preferences: (Fig. 3)

a. Uncheck View Adobe PDF results.

b. Click on the “Browse…” button to change the Adobe PDF Output Folder setting.

c. Select Adobe PDF Output the click OK. Then click OK in the Adobe Acrobat PDF Printing Preferences window. (Fig. 4)

In Zümmer, when the Print command button is clicked, all the selected reports will then be immediately routed to the folder “Adobe PDF Output”. Later, you can view all the PDF files when the print job is complete. A typical Zümmer output run will take just a few (2 or 3) minutes to process.

The smallest PDF files by file size are usually blank (about 5-6K indicating that there were no results for that report), therefore, they can be sorted and deleted all at one time.

The instructions above apply to your computer’s user setting. Therefore, this will affect all applications. If you don’t want our printer settings to change then disregard these instructions.

Stressed vs Relaxed CPM Networks

Use the Total Float Distribution Curve to evaluate the condition of a CPM Network.

Analyzing and understanding the distribution of Total Float (TF) values in a CPM network can be a very revealing and useful indicator. In general, CPM networks with a more “Stressed” Distribution tend to be more sensitive to Project delays as compared to networks with a more “Relaxed” Distribution.

Zümmer’s Float Distribution Curve analysis report provides a graphical chart that can help you quickly determine the condition of the CPM Network. The generated graph plots the Total Float Values along the X-Axis, while the Y-Axis plots a Percentile value indicating the percentage of Tasks that have the X-Axis Float Value or less.

In the illustration below, for the “Stressed” Distribution graph, the range of Total Float Values is from 0 to about 1,210 (along the X-Axis) for the 2,243 Tasks distributed. However, at the 50% Percentile point (along the Y-Axis); the Total Float Value is about 50. In other words, about half of all the Tasks (approximately 1,121 Tasks) in this Project have a Total Float Value of 50 or less.

Similarly, in the illustration below, for the “Relaxed” Distribution graph, the range of Total Float Values is from 0 to about 870 (along the X-Axis) for the 2,725 Tasks distributed. However, at the 50% Percentile point (along the Y-Axis); the Total Float Value is about 175. In other words, about half of all the Tasks (approximately 1,362 Tasks) in this Project have a Total Float Value of 175 or less.

In comparison, and all else being equal, Projects with “Stressed” distribution are more likely to experience delays as compared to Projects with “Relaxed” distribution.

Determining a “Rule-of-Thumb” is subject to debate, however, by observation, Float Distribution Curves that are steep on the left side and flat on the right side, generally fall in the “Stressed” category. Whereas, Float Distribution Curves that are smooth from beginning to end generally fall in the “Relaxed” category.

Very Stressed distributions could be a cause for alarm since this may indicate a Project schedule that is “Claims oriented”. In these cases, you may want to consider reviewing the Project’s overall logic schema to determine where relationships can be removed or revised thereby increasing overall Total Float values.

Very Relaxed distributions could also be a cause for alarm since this may indicate a Project schedule that is insufficiently developed. In these cases, you may want to consider reviewing the Project’s overall logic schema to determine where relationships can be added or revised thereby decreasing overall Total Float values.