The PDM (Precedence Diagram Method) method of defining relationships between activities is a powerful tool. Often, however, Schedulers, sometimes unknowingly, misuse the options available when defining relationships between activities. In the illustration below, under Method 1, Activity “B” is related to “C” using Finish-To-Finish (FF) with Lag = 0.
This may appear as a reasonable approach as often, the Activity Name description(s) may provide a false justification for this relationship. Unfortunately, the Forward and Backward pass doesn’t care about your Activity Name description. Therefore, trying to justify the use of Method 1 by using a “real world” situation fails as an argument to promote its use.
The Forward and Backward Pass doesn’t care about your Activity Name description.
In Figure 1 above, by observation, since “C” has a shorter duration than “B”, the Early Start (ES) for “C” is misrepresented since “C” can start at the completion of “A”. Furthermore, the Total Float (TF) is equally misrepresented since the Early Finish (EF) is the same as “B”.
If there is no lag(say this to yourself a few times) between “B” and “C”, then the finish of both “B” and “C” are equally responsible for starting “D”. Neither “B” or “C” have priority over controlling the start date of activity “D” with respect to logic. With respect to Duration however, activity “B” alone controls the start date of activity “D”. Therefore, the correct approach is to relate “B” FS to “D”.
In Method 1 above, activity “C” is behaving as if it was constrained using the “As Late as Possible” option. By misrepresenting the ES of “C”, the result could lead to an inadvertent impact to the Project Completion date by starting “C” too late. This could cause a loss of trust in the schedule. The solution is to follow Method 2, i.e. “B” is related to “D” using FS. Not only is this trap avoided but relationships between activities are more clearly defined.
After all this, if you’re still not convinced and still feel the need to use the FF 0, then consider re-assigning the scope of work between Activities “B” and “C”. Consider separating the scope of the tasks so that the finish portion of Activity “C” is now included as part of Activity “B” and the start portion of Activity “C” starts at the completion of Activity “A”. Normalizing CPM Network logic to the basic Finish-to-Start relationships avoids confusion and possible erroneous Start/Finish dates and Total Float values.
Zümmer checks this anomaly with Report #35 – “Tasks With Finish-to-Finish Relationships And No Lag” reports all instances. In the illustration below, each Finish-To-Finish relationship with no lag is clearly and individually paired. In addition, the Activity Status of the predecessor and successor is listed along with each Original Duration, Total Float, type of Relationship and lag value between the two activities. Relationships with lower Total Float values have a higher resolution priority over relationships with a higher Total Float value.
Generally, in a CPM Network, lag
values should be smaller than the duration values of either its predecessor or
successor activity. In other words, lags
should not cause gaps in the flow of activities through the CPM network.
Unfortunately, this is a very easy mistake to make and worse, far more
difficult to detect.
There are 4 possible cases where a
non-overlapping lag may occur:
Case 1:
The Negative Lag is greater than the sum of the Predecessor’s Original Duration and the Successor’s Original Duration (Figure 1).
Figure 1
Suppose the Original Duration
(OD) for Activities “A” and “B” are set to 5 Days each and the relationship is
set to Finish-To-Start (FS) with a lag of -9 Days. This is overlapping since
the sum of the durations of “A” and “B” is 10 Days.
Now Suppose, the OD for
activities “A” and “B” are each reduced to 2 Days. Unless the relationship
between “A” and “B” is changed, a non-overlapping condition will occur (Figure
1) since the absolute value FS lag of -9 Days is greater than the OD of “A”
plus the OD of “B” (now at 4 Days). The gap between activity “A” and “B” is now
5 Days caused by the non-overlapping lag.
In P6, no Filter that can be
constructed to check for this type of Non-Overlapping Lag.
Zümmer Analysis Report #31 – “Negative
Lag Greater Than Sum of Both Original Durations” identifies the Non Overlapping
lag condition “Neg Lag > Pred OD + Succ OD”. In the Figure 2 below, each non-overlapping
relationship is clearly and individually paired. In addition, the Activity Status
of the predecessor and successor is listed along with each Original Duration,
the type of Relationship and lag value between the two activities.
Figure 2
Case 2:
A Positive Finish-To-Start lag is used between 2 Activities (Figure 3)
Figure 3
Suppose the Original Duration
(OD) for Activities “A” and “B” are set to 7 Days each and the relationship is
set to Finish-To-Start (FS) with a lag of -2 Days. This is overlapping since
the sum of the durations of “A” and “B” is 14 Days.
Now suppose the lag value is then
changed to +7 Days. The gap between activity “A” and “B” is now 7 Days caused
by the non-overlapping lag.
In P6, no Filter that can be
constructed to check for this type of Non-Overlapping Lag.
Zümmer Analysis Report #32 –
“Activities with Finish-To-Start Relationship & Positive Lag” identifies
the Non Overlapping lag condition “FS with Positive Lag”. In Figure 4 below,
each non-overlapping relationship is clearly and individually paired. In
addition, the Activity Status of the predecessor and successor is listed along
with each Original Duration, the type of Relationship and lag value between the
two activities.
Figure 4
Case 3:
A Start-To-Start Lag is greater than the Predecessor’s Original Duration (Figure 5).
Figure 5
Suppose the Original Duration
(OD) for Activities “A” and “B” are set to 15 Days and the relationship is set
to Start-To-Start (SS) with a lag of 8 Days. This is acceptable since “A” and
“B” overlap.
Suppose now, the OD for “A” is reduced to 5
Days. Unless the relationship between “A” and “B” is changed, a non-overlapping
condition will occur since the SS lag of 8 Days is greater than the OD of “A”
(now at 5 Days). The gap between activity “A” and “B” is now 3 Days caused by
the non-overlapping lag.
In P6, no Filter that can be
constructed to check for this type of Non-Overlapping Lag.
Zümmer Analysis Report #33 – “Start-To-Start
Relationships & Lag Greater Than Predecessor’s Original Duration” identifies
the Non Overlapping lag condition “SS Lag > Predecessor OD”. In Figure 6
below, each non-overlapping relationship is clearly and individually paired. In
addition, the Activity Status of the predecessor and successor is listed along
with each Original Duration, the type of Relationship and lag value between the
two activities.
Figure 6
Case 4:
A Finish-To-Finish Lag is greater than the Successor’s Original Duration (Figure 7)
Figure 7
Suppose the Original Duration
(OD) for Activities “A” and “B” are set to 15 Days and the relationship is set
to Finish-To-Finish (FF) with a lag of 8 Days. This is acceptable since “A” and
“B” overlap.
Suppose now, the OD for “B” is
reduced to 5 Days. Unless the relationship between “A” and “B” is changed, a
non-overlapping condition will occur since the FF lag of 8 Days is greater than
the OD of “B” (now at 5 Days). The gap between activity “A” and “B” is now 3
Days caused by the non-overlapping lag.
In P6, no Filter that can be
constructed to check for this type of Non-Overlapping Lag.
Zümmer Analysis Report #34 – “Finish-To-Finish
Relationships & Lag Greater Than Successor’s Original Duration” identifies
the Non Overlapping lag condition “FF Lag > Successor OD”. In Figure 8
below, each non-overlapping relationship is clearly and individually paired. In
addition, the Activity Status of the predecessor and successor is listed along
with each Original Duration, the type of Relationship and lag value between the
two activities.
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?
Figure 1
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.
Figure 2
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).
Figure 3
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.
Figure 4
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.
Figure 5
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.
Figure 6
When the Time option is set to 24 Hours, the following values appear in Figure 7 below.
Figure 7
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.
Figure 8
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.
Figure 9 Figure 10
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”
Figure 11
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.
Figure 12
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.
Figure 13
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.
Figure 14
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.
Figure 15
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.
Finding Out-of-Sequence activities can be a time-consuming effort.
During the update process of a CPM Network it’s often likely to end up with Out-of-Sequence activities.
There are multiple causes for and multiple types of out-of-sequence conditions. The most common cause is when a successor activity is statused as started however the predecessor activity has not completed.
Especially in large CPM networks, with many activities statused during an update period, finding the root cause of an out-of-sequence condition can be a difficult task.
Consider for example, a situation, as shown below where an Activity “A” has not started and has only one predecessor, Activity “P1” that has completed. Typically, you would expect Activity “A” to start on the Data Date. However, as a result of scheduling using Retained Logic, Activity “A” is out-of-sequence by a number of days equaled to the remaining duration of activity “B”.
In this example below, tracing the logic back through 6 predecessors, Activities “P1” through “P6” finally arrives at the offender, Activity “B”. In this example, Activity “B” is the “not completed activity” while Activity “P6” is the “started successor”.
Finding out-of-sequence conditions using this technique and P6 alone can be a time consuming and frustrating effort. Especially if there are multiple logic paths that precede Activity “A”.
Zümmer Analysis Report #23 – “Not Complete Activities With Started Successor” list all activities that are Not Complete, and a successor is either In Progress or Completed.
In the illustration above, Line Item #1, Activity TD0012572, has not started and Activity 404-CM-1040, one of its successors, is complete. In Line Item #2, Activity TD0016440, has not started and a successor, Activity TD01010, is in progress.
The report sorts relationships by Predecessor/Successor Activity ID and the Predecessor/Successor Activity Name. The report then lists the Predecessor’s Early Finish, the Successors Actual Start, then continues with the Predecessor/Successor Original Duration, then the Relation Type and Lag value.
Other Zümmer Analysis Reports that fall in the “Out-Of-Sequence” category includes:
Analysis Report #24 – “Out-Of-Sequence In Progress Tasks”
Analysis Report #25 – “Not Started Activities with No Active Predecessors”
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.
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.
“Behind the scenes” calendar changes can result in perplexing date changes (or lack thereof) between Project Updates.
Changing calendar settings is an easy (and sometimes underhanded) way to “block out” days in the calendar thereby changing schedule dates.
Zümmer’s Comparison Report #44 – Changed Calendar Settings – reports and detects these types of changes. It is possible for Global and/or Project Calendars to have the same Calendar Name yet have different calendar settings. Detecting this type of change is extremely difficult and time consuming using P6 alone.
The Change Calendar Settings report compares the 2 Project Calendar Settings and identifies any added and deleted Calendar assignments. In addition, the report lists the Calendar Name, Type of Calendar used (i.e. Project or Global), Hours per Day setting, and Count (# of activities using that Calendar).
Added Calendars have no Control Project ID Calendar Name match while deleted Calendars have no Modified Project Id Calendar match.
In the illustration below: Line Item #4 – A Global Calendar was assigned to 1 activity. Line Item #3 – The Calendar Name, Type and Hrs/Dy match exactly, however (indicated by the Asterisk) there was a change in the underlying Calendar Data set. In other words, for example, one or more days were changed from a Standard to Non-work day or visa-versa.
Changes to Calendar Data may also involve other settings. This report does not identify exactly what Calendar Data changed, however, knowing that there is a change is sufficient to warrant further investigation.
