Tips, Trap, Tricks – Page 2 – The Official Site for Zümmer

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.

Trap: “Must Finish By” constraint at 00H: 00M

If in the User Preference window, the Dates-> Time option is set to “Do not show time”, then P6’s schedule calculation of Total Float values could be incorrectly calculated when a date is entered in the Project –> Schedule Date –> Must Finish By textbox.

When time is not shown and a date is entered in the Must Finish by textbox, the time stored by default is: 00H: 00M. This means that the date shown will not be considered during P6’s schedule calculations during the backward pass. This oversight causes every Total Float value to be 1 day less than the correct Total Float value.

In the illustration below, the “Analysis Charts 1 of 2” reports 4 activities with negative float even though the “Must Finish By” date matches the Contract Completion Milestone in the schedule.

Zümmer’s Analysis Charts, Analysis Statistics and Project Settings reports provide the red alert message “Possible Bad Planned End Date – Check Planned End Date Hours” under the Planned End box when the “Must Finish By” constraint date contains “00H: 00M” as the time value.

When this situation occurs, first return to the User Preferences window then change the Time option setting to either “12 Hour (1:30 PM)” or “24 Hour (13:30)”.

Second, return to the Projects-> Dates option. the “Must Finish By” option will now show with the Hours, Minutes as “00:00”.

Then change the hours and minutes setting to reflect the ending hour and minutes settings for the Project (typically 17:00/5:00 PM or 16:00/4:00 PM) as shown below.

Lastly, recalculate the Project as normal. The resulting Total Float values will now correctly include the Finish date during the backward pass process.

Retained Logic, Progress Override and Actual Dates

Retained Logic, Progress Override and Actual Dates

There are many of articles regarding this topic on the internet. If you’re still not clear about the difference, below is an explanation presented as simply as possible.

In the illustration above, Activity B is assigned an Actual Start and Actual Finish date LATER than the Data Date. This condition is not considered “best practice” since there should be no Actual Dates later than the Data Date; however, this assignment is necessary to illustrate the difference between Actual Dates and Retained Logic. When there are no Actual Dates later than the Data Date, then Actual Dates and Retained Logic generally behave the same. The difference among the 3 options is reflected in the different Start and Finish dates for Activity C.

In Figure 1, using ACTUAL DATES, Activity C starts after the Actual Finish date for Activity B.

In Figure 2, using RETAINED LOGIC, Activity C ignores the Actual Dates of Activity B and starts after the Finish Date from Activity A.

In Figure 3, using PROGRESS OVERRIDE, since Activity B is “progressed” with Actual Dates, Activity’s C logic is “overridden” and therefore starts on the Data Date.

In summary, the method used to schedule the CPM network could have significant differences in determining the Start and Finish dates. Most contract specifications require the use of Retained Logic. There are many articles that can be found on the internet that cover this issue in greater detail to include effects on earned value and other properties.