How to detect and avoid those “stealthy” lag changes.
Maintaining a Project’s Completion Date is great but not by implementing what could be considered as concealing or under-handed measures.
In the illustration above, Test Project 1 – Update 01 with Data Date 17-May-20, highlighted Activity “C” is forecast to complete on 07-Jul-20. However, in the Test Project 1 – Update 02 with Data Date 17-Jun-20, Activity “C” has slipped by 14 calendar days to 21-Jul-20.
Miraculously:
the Project has maintained its Completion Date at 01-Sep-20 and;
The Finish date for Activity “D” remains at 28-Jul-20.
How did this happen?
There are many ways to manipulate a CPM network to mask lack of progress. One typical way involves introducing either a negative lag or reduced lag values especially along the critical path.
In the example above, The FF lag between Activity “C” and Activity “D” was reduced from 15 to 5 days, and a lag of -10 days was introduced into the FS relationship between Activity “C” and Activity “E”.
These subtle changes are difficult to detect since the graphical representation of the logic relationships are remarkably similar as shown in the illustration above. In a large CPM network, lag changes of this type can be easily missed.
Zümmer identifies these changes under Comparison Report #08 – “Logic Changes To Lag Only”. In the illustration below, Line Item #1 reports the FF lag change from 15 days to 5 days between Activity “C” and Activity “D” and; Line Item #2 reports the introduction of a FS negative lag of -10 days between Activity “C” and Activity “E”.
Since Lags are a property of Logic Relationships, a change in the Lag value is considered a change to the CPM logic and is reported as a logic change in other Zümmer comparison reports.
If you are receiving periodical CPM schedule updates and encounter these type of changes, it is especially important to report these issues back to the submitter so that further CPM logic changes of this type are prevented.
How to compare and report changes to the “Driving” Path
Comparing Driving Path Activities:
Determining and understanding how the Critical, Longest or Driving Path changes when comparing one update from another is an important part of a Scheduler’s responsibilities.
Regardless of how critical activities are defined in the Project Settings, internally in the P6 Project’s task database, the field name that flags critical activities is labeled as “driving_path_flag”. Therefore, for the purposes of this report and article the term “Driving Path” is used.
Some questions a Scheduler needs to answer:
What newly added activities are now on the Driving Path?
What activities are no longer on the Driving Path?
What Driving Path activities were completed?
What activities were deleted that were previously on the Driving Path?
The Zümmer Driving Path Activity Comparison provides this valuable information (and more) in a smartly designed and structured format.
In the Driving Path Activity Comparison Report:
The “Control” Project (as shown below) is defined as the Project Id that is being compared to. The Control Project is typically the Project update that has the earlier Data Date when compared to the “Modified” Project. In this case, the Data date is June 1, 2020.
The Modified Project (as shown below) is defined as the Project Id that is being compared against the Control Project. The Modified Project is typically the Project update that has later Data Date. In this case, the Data date is July 1, 2020.
In the detail band (as shown below), the Driving Paths from both the Control and Modified Projects are listed in an outer join format ordered by Activity ID. The list displays a line number count, the Control Project Status, Modified Project Status, Activity ID, Activity Name, Activity Type, Control Project Driving Path Activity flag, Control Project Remaining Duration, Control Project Total Float, Modified Project Driving Path Activity flag, Modified Project Remaining Duration, Modified Project Total Float and the Total Float variance.
Shown above, for Line Items #1 and #2: The activity status for each was changed from “Not Started” to “Completed”. Note that since these activities are completed, the Remaining Duration, Total Float and Total Float variance values are not applicable and therefore not displayed.
Shown above, for line item #3: This activity is on the Driving Path in both schedule updates. Note that the status changed from “not started” to “in progress” when Update 02 (the Modified Project) is compared to Update 01 (the Control Project).
Shown above, for line item #4 (as well as #6 thru #11 and #15): This activity is on the Driving Path in both schedule updates. Since the status remained unchanged as “Not Started”, it would be expected that the remaining duration would remain the same and the Total Float value would remain at 0.
Shown above, for line item #5 (as well as #12 and #14): This activity was on the Driving Path in schedule Update 01, however under Update 02, it is no longer on the Driving Path. The Total Float value for line item #5 changed from 0 to 2 days; or an increase variance of 2 days of Total Float.
Shown above, for line item #13: This activity was not on the Driving Path in schedule Update 01, however under Update 02, it is on the Driving Path. The Total Float value also changed from 4 to 0 days; or a decrease variance of 4 days of Total Float.
Shown above for line item #16: Since there is no status designation, Remaining Duration and no Total Float value for Update 01, this activity was added in Update #02 and inserted as a Driving Path activity.
In the page footer section shown below, a legend is for Activity Type and a legend for Activity Status is provided. In addition, the Run Date and Page numbering is provided.
Once printed, the Driving Path Activity Comparison Report can be directly inserted into a Submittal document with no further manipulation and provide documentation to support your review narrative. Additional similar Zümmer comparison reports include: “Added Driving Path Activities” and “Deleted Driving Path Activities”.
Print a smarter and more efficient Predecessor Successor Report
Print a clear and concise Predecessor Successor Report from Zümmer
A CPM Schedule “Predecessor Successor Report” is a standard and valuable tool for documenting and examining an activity’s predecessor and successor relationships. However, creating this type of report in P6 is not only time consuming and difficult, but the resulting output is typically tough to read and cryptic. Even worse, this type of report, which is typically lengthy to begin with, is even more lengthy when using the formats available in P6’s reporting tools.
Zümmer’s version of the Predecessor Successor Report is not only concise and well organized but also contains more pertinent information than most other Predecessor Successor Reports found in many “How To” articles found online.
Page Header – Project ID Information
The Page header shown above displays the Project ID, Project Name and Data Date for the selected Project.
Group Header – Activity Information
Each Group is sorted alphabetically by Activity ID. The Group header band starts with a light red shaded area and displays the Activity Status, Activity ID, Activity Name, Activity Type and Total Float value. The Total Float is not shown for activities that are completed.
Each Activity ID in the Group Header band is prefixed by “*”. This allows for quick searching within a PDF or other electronic type file. For Example, in the sample above, to find the Predecessors and Successors for Activity “MPBR3590”, type “*MPBR3590” in the search window. This will find the Group Header Activity ID instead of the same Activity ID that might exist in the Predecessor/Successor detail band.
Detail Band – Predecessors and Successors
Directly below the Group Header Band is the Predecessor/Successor detail band. This detail band is sorted first by Predecessor shown in a blue font then by Successors shown in a red font. Within each Predecessor/Successor band, the activities are listed alphabetically by Activity ID and displays the Relationship type (“P” for Predecessor and “S” for Successor), Activity Status, Activity ID, Activity Name, Activity Type, Total Float value, Relationship Type and Lag value.
Page Footer – Legend Information
The Page footer displays a Legend for the Activity Type, a Legend for the Activity Status, the Run Date (date printed) and the Page numbering.
Report Total – Project Logic Count
On the final page, a total count of all the logic relationships is displayed.
Once printed, the Predecessor Successor Report can be directly inserted into a Submittal document with no further manipulation.
Use these 4 Zümmer Analysis Reports to keep your Resource Cost and schedule in sync.
Keeping Resource Costs and schedule status in-sync can be a nightmare even in a moderately sized CPM Network. In this type of environment, it is possible to have an independent Cost Engineer and Schedule Engineer responsible for developing and maintaining Resource Costs and schedule making this effort even more complicated.
In an ideal situation, Resource Costs and schedule status are In-Sync when:
1) an activity has not started, and the Actual Resource Cost (Expenditures) is equaled to 0;
2) an activity is in-progress, and the Resource Cost Actual Cost To-Date is be between 0 and the Budgeted Cost;
3) an activity is complete, and the remaining Resource Cost is 0.
Obviously, the ideal situation is rarely the case and, in some instances, can even be justified. Regardless, when schedule and Resource Cost status get Out-of-Sync, these instances should be identified, reviewed, and adjusted accordingly.
There are 4 Out-of-Sync possibilities: (See illustration below)
1) Resource Cost exist on activities that have not started.
2) There is Remaining Resource Cost on activities that are complete.
3) There is no Remaining Resource Cost on activities that are in-progress.
4) There is no Actual Resource Cost on activities that are in-progress.
Zümmer checks for Possibility #1 with Analysis Report – “Expenditures on Not Started Tasks” illustrated below.
Zümmer checks for Possibility #2 with Analysis Report – “Remaining Cost On Completed Tasks” illustrated below.
Zümmer checks for Possibility #3 with Analysis Report – “No Cost to Complete on Tasks in Progress” illustrated below.
Zümmer checks for Possibility #4 with Analysis Report – “No Cost To Date on Tasks in Progress” illustrated below.
Each report lists the Activity ID, Activity Name, and either Budgeted Cost, Cost to Complete, or Expended Cost value. Line Items are highlighted when an unbalanced condition occurs. Unbalanced conditions occur when the Budgeted Cost is not equaled to the Actual Cost plus the Remaining Resource Cost value.
Use these 4 Zümmer Analysis Reports to keep your expenses and schedule in sync.
Keeping expenses and schedule status in-sync can be a nightmare even in moderate sized CPM Networks. In this type of environments, it’s possible to have an independent Cost Engineer and Schedule Engineer responsible for developing and maintaining expenses and schedule making this effort even more complicated.
In an ideal situation, expenses and schedule status are In-Sync when:
1) An activity has not started, and the Expense Actual Cost to-date is 0;
2) An activity is in-progress, and the Expense Actual Cost To-Date is be between 0 and the Budgeted Cost
3) An activity is complete, and the Expense Remaining Cost is 0.
Obviously, the ideal situation is rare and in some instances, can even be justified. Regardless, when schedule and expense status get Out-of-Sync, these instances should be identified, reviewed and adjusted accordingly.
There are 4 Out-of-Sync possibilities: (See illustration below)
1) Expense Actual Costs exist on activities that have not started.
2) There is Expense Remaining Cost on activities that are complete.
3) There is no Expense Remaining Cost on activities that are in-progress.
4) There is no Expense Actual Cost on activities that are in-progress.
Zümmer checks for Possibility #1 with Analysis Report #48 – “Actual Expenses On Not Started Tasks” illustrated below.
Zümmer checks for Possibility #2 with Analysis Report #49 – “Remaining Expenses On Completed Tasks” illustrated below.
Zümmer checks for Possibility #3 with Analysis Report #50 – “No Remaining Expenses on Tasks in Progress” illustrated below.
Zümmer checks for Possibility #4 with Analysis Report #51 – “No Actual Expenses on Tasks in Progress” illustrated below.
Each report lists the Activity ID, Activity Name, Budgeted Expense, Actual Expense and Remaining Expense value. Line Items are highlighted when an unbalanced condition occurs. Unbalanced conditions occur when the Budgeted Expense is not equaled to the Actual Expense plus the Remaining expense value.
Nearly every P6 Export File I have ever received has a Global Calendar embedded in it.
Many construction project specifications state that Global Calendars and Global Activity Codes (Global Activity Codes will be discussed in a separate article) are not to be included in the Project Schedule. The reason is that the Owner or Agency wants to control the number of Global Calendars in their P6 CPM Network.
Imagine a large agency such as a State Department of Transportation that receives Project schedules from scores of Contractors. If the Global Calendars are not properly managed, the agency can easily wind up with literally hundreds of Global Calendars. Many of these Global Calendars may not be easily attributable to a source Project. Some may be overtly faulty, expired and inadvertently assigned to activities from a different Project.
The worse-case scenario occurs when an existing Global Calendar is possibly overwritten by an imported Global Calendar of the same name. Just think of how many Global Calendar are named “Standard 5 Day Calendar”
In general, Global Calendars are
intended to be used only for creating Project or Resource Calendars. Therefore,
Global Calendars should never be transferred from one party to another.
For those submitting Project
Schedules to other parties, make sure that Global Calendars are not included in
the export file (typically the .XER file). Submitting Global Calendars to other
parties not only populates other P6 Users with superfluous Global Calendars but
is bad form and must be avoided.
For those receiving Project
Schedule from other parties, make sure that the import file (typically the .XER
file) does not contain Global Calendar. Otherwise, before long, your Global
Calendar list will contain scores of unrecognized and unassigned Global
Calendars with the potential of invalidating your CPM network.
Sadly, of the countless number .XER/.XML files I have received over the past 15 years (or so), nearly ALL of them contain references to a Global Calendar.
The reality is that most P6 Users (who may not necessarily be a “Scheduler”) don’t even realize that they are sending Global Calendars. Similarly, many P6 Users are not even aware of that the problem exists. Even then, if you’re aware of the issue, you could still be sending Global Calendars and not know how or why they are mysteriously propagating into your Export Files. Keeping Projects Global Calendar free is not as easy as you may think.
Unfortunately, there’s no export
option that reads “Omit Global Calendar References”. Therefore, below, I have
outlined a Step-By-Step procedure that will help you root out Global Calendars
from your export files.
Step 1: Establish a naming
convention that clearly distinguishes Global Calendars from Project Calendars.
In the illustration below, “**GC-99” has been added as a prefix to all existing Global Calendars. To ensure all are unique, the Global Calendar sequence was numbered from “00” to “15”. From this point forward, it will be easy to spot whenever Global Calendars are used in a Project. In addition, any new Global Calendars that have been inadvertently imported from an unvetted file can be easily and quickly identified.
Step 2: Make Sure no Activities in the Project are assigned to a Global Calendar.
Now that all Global Calendars are
clearly defined, Open the Project and set the Filter ‘All Activities’. Next,
Group & Sort by Calendar then collapse to ‘Calendar Level 1’. The result
should appear like image below.
In the image above, it’s easy to see that Project activities
are assigned to Global Calendars “**GC-00” and “**GC-06”.
From this point, reassign the activities with Global
Calendars to Project Calendars.
Step 3: Make Sure all Project Calendars are not inheriting from a Global Calendars.
From the Enterprise Main Menu, select “Calendar”. The Calendar window appear as shown below displaying all the Project Calendars created for the Project.
For each Project Calendar listed, click the Modify command button to display the window shown below:
For “TS-01 – 5 Day WrkWk – Gen’l Construction w/Holidays (Thru 2018)”, the Project Calendar is inheriting from “**GC-13 – Standard 5 Day Workweek”. Revise the inheritance setting to <None>. Continue this process for all Project Calendars regardless of whether the Project Calendar is assigned to an activity or not.
Step 4: Make Sure the Default Calendar is not a Global Calendar.
Whenever a new Project is
created, P6 automatically assigns the Global Default Calendar as the assigned
Default Calendar for the Project. As shown below, the selected Project defaults
to a Global Calendar when a new activity is added to the Project. Even if all
activities are assigned to a Project Calendar, having the Default Calendar set
to a Global Calendar will cause P6 to embed the Global Calendar when an export
file is created.
To remove the Global Calendar as the Default Calendar, first Open the Project, then select a Project Calendar as the Default Calendar. When the Project is closed and the Project is highlighted in the Projects Tab, no Default Calendar will be shown in the textbox. To see the assigned Calendar, simply re-open the Project then return the Projects-Defaults Tab.
Step 5: If you are using Resources, make sure the are using a shared or Personal Resource Calendar.
All Resources are assigned a Calendar which can be viewed in the Details ->Profile selection window. When a new Resource is created from scratch, P6’s designated Default Project Global Calendar is automatically assigned as the Default Calendar for the Resource. In the illustration below, the Carpenter resource Calendar Profile is assigned to a Global Calendar.
Resources can either be assigned
to a Personal Calendar or be assigned to a previously created Shared Resource
Calendar.
To prevent a Global Calendar from making its way into the .XER/.XML file, all Resources that are assigned to the Project’s activities must be assigned to either a Shared Resource Calendar or a Personal Calendar. Furthermore, whether a Shared Resource or Personal Calendar is used, the assigned Calendar must not be inheriting from a Global Calendar (See Step 3 above).
Step 6: Use the VFR (Visual File Review) technique to verify no Global Calendar references are contained in the .XER File.
Checking an .XER for Global Calendars is easy. Simply open the file using a text editor such as Notepad then scroll down to the Calendar Table (%T) section as shown below:
Below that line, look for a Record line starting with (%R). Reading to the right, the 7th field, which displays the record value for Field Name (%F) “clndr_type” is displayed. The three possible Record values for the Field “clndr_type” (Calendar Type) is:
CA_Base: Identifying a Global Calendar;
CA_Project: Identifying a Project
Calendar;
CA_Rsrc: Identifying a Resource Calendar.
If “CA_Base” exists as a Calendar Type, then a Global Calendar exists for the Project contained in the .XER File. In this case, return to P6, then reopen the Project, then go through Step 1 through 5 until you find offending Global Calendar assignment. Although, I don’t have an .XML example, the same approach applies.
Keeping “Lean & Mean” Global
Calendar free Projects helps stop the proliferation of redundant and
superfluous Global Calendars.
If you find this article useful,
I encourage you to pass it along to your P6 scheduling colleagues.
Tracking logic changes can be a nightmare,
especially when it comes to large CPM networks with ever changing scope and
conditions. Many schedule specifications require that for each logic change, a
description for the basis of each change is provided and specifically
identifying the affected activities by Activity ID. In other words, the Owner
is not just interested in what changed, but more so, why the change was made.
Making matters worse, typically each change requires an individual explanation.
Comparison Report: Changed Logic To Existing Activities – shown below groups predecessor logic changes by Activity ID. The action taken, Added or Deleted Predecessor, is coded as AP or DP. The report also displays the Activity Name, Relationship, Lag and Total Float values. The advantage of this report is that all relationship changes including Predecessors and Successors whether deleted or added for any particular Activity ID is consolidate in one place.
Viewing only logic changes to existing activities removes all other Logic changes that were created as a result of adding or deleting activities between the Control and Modified Projects. This approach focuses attention to logic changes that were intentionally made to existing activities.
Tracking and identifying changes to the critical, longest
and driving paths is an important part of a Scheduler’s responsibilities. The
term “Driving Path” is the generic term P6 uses within its database to flag the
path that the User defines as either the Longest Path or Critical Path for the
Project.
In the Driving Path Activity Comparison report shown below. Line item activities 64 and 65 were on the Driving Path in the Control Project, however, they are no longer on the Driving Path in the Modified Project. Item #66 remains on the Driving Path for both Project Updates.
Items 68 thru 73 were added as part of the Modified Project, TS-BL3-UP29. As a result of being added during Update #29, these activities now fall on the Driving Path. The added activities also removed activity line items 64 and 65 from the Driving Path and increased their Total Float value from 0 to 24.
In addition, Item 77 is no longer on the Critical Path is the activity was actualized.
The report lists the Activity ID, Activity Name, Activity Type, the Control Project’s Driving Path Flag, Remaining Duration & Total Float, the Modified Project’s Driving Path Flag, Remaining Duration and Total Float. The Variance between Total Float value is the difference between The Modified Total Float and the Control Total Float values.
When it comes to adding logic
relationships in P6, things can get out-of-hand in no time. During the CPM
network development phase, logic relationships are constantly added, deleted
and revised. At the completion of the process the CPM network diagram can end
up looking like a messy bowl of spaghetti.
Good scheduling practice calls for minimizing, as reasonably as possible, the amount of logic relationships in the CPM network. Cluttered CPM networks can add confusion, promote faulty logic and increase errors especially when trying to trace logic paths.
Before diving further into this topic, and for the purposes of this discussion, we must first define our terms and the difference between “Redundant Relationships” and “Duplicate Relationships”.
A Redundant Relationship is defined as: an additional logic relationship between 2 activities that are not directly related to each other.
In the example below, the FS relationship between Activity B (B) and Activity H (H) is redundant because an existing inferred relationship between these 2 activities already exists through B->C->D->E->F->G->H. Since B and F are not directly related, then the relationship B->F is said to be “Redundant” since intermediate activities exists between each activity which are along the same logic path.
Since the relationship B->H is redundant, then this relationship can be safely deleted and will not affect any dates or Total Float values of any activity within the CPM network. Redundant relationships are easily detectable when a logic path is neatly grouped so that activities of the same logic path are sorted by start date. In the example below, activities B thru G are group in the same logic path and are sorted by Start date. The 3 redundant relationships are clearly shown (B->H; C-> E; and E->G) by the dotted relationship lines and therefore can be safely deleted.
Even though a redundant relationship exists, it doesn’t necessarily mean that the relationship should be deleted. A Scheduler may decide to intentionally retain a redundant relationship in the CPM Network. For example, the redundant relationship may represent a secondary “fallback” relationship in case the current driving relationship is not sustainable.
For example, in the illustration above, suppose the current driving predecessor (D) to Activity E is no longer valid. Then, by removing the relationship, D->E, then the new driving predecessor to E will be C. If the redundant relationship, C->E had been previously removed, then when the relationship D->E is removed, E will revert back to the Data Date when the schedule is recalculated.
For this reason, using redundant relationship removal algorithms is generally not recommended. Furthermore, and unfortunately, when it comes to P6, all relationships (other than the relationship type) are the same. There is no direct way to differentiate “soft” relationships from “hard” relationships; or “primary” relationships from “secondary” relationships; or “physical” relationships from “crew” relationships.
Redundant relationship removal algorithms generally remove relationships regardless of their priority or classification. Therefore, the recommended method for removal of relationships is by individual consideration and inspection.
A Duplicate Relationship is defined as: an additional logic relationship between 2 activities that are directly
related to each other.
Duplicate relationships can be
classified into 2 types.
In the illustration above, the first
type (Type 1) of Duplicate Relationship occurs when a SS/FF relationship pair is
used. Typically, a lag value (typically greater than 0) is
included in both relationship. This relationship technique is often used in
summary level type schedules where the activity detail is not totally defined. Since
the preferred technique in CPM networks is to allow only 1 relationship between
any 2 activities, this usage is not recommended for detailed or production level
schedules.
The second type (Type 2) of
Duplicate Relationship occurs when the relationship pair is not of the SS/FF
type. These duplicate pairs often occur when the “Link Relationship” option is
inadvertently used a second time (or more) spanning activities that are already
related. In most cases, the non-driving relationship is the relationship that
should be deleted. Therefore, for K->L, the FF duplicate relationship can be
safely deleted.
A subset of the Type 2 Duplicate Relationship is the “Multiple Instances” variety where more than 2 Duplicate Relationships exist between 2 activities. An example of this, as shown below, displays the relationships between M->N where every possible logic relationship exists between the 2 activities.
In the Successors relationship
window above, since the Driving relationship is FS, then all other listed
relationships can be safely deleted.
Zümmer’s Analysis Report #39 – “Duplicate Logic Relationships” shown below, lists all duplicate logic relationships in the selected Project.
This report groups duplicate logic
relationships separated by a heavy horizontal line. In the example above, the
duplicate logic relationship between M->N displays the Type 2 variety with all
4 assigned relationships. For this condition, the FF, SF and SS relationships
can be safely deleted.
The next group, between K->L,
displays the Type 2 variety with the FF/FS pair. For this condition, the FF
relationship can be safely deleted.
The last group, between I->J, displays the Type 1 variety with the SS/FF pair. Here, the I->J relationship contains a lag of 5 days for both SS and FF relationships. If Activities I & J are part of a detail production level schedule, then breaking down the scope into more detailed activities may be necessary to eliminate the duplicate logic condition.
The Filter option is probably the Scheduler’s most powerful
tool in P6. The Filter option allows the Scheduler to display only specific
activities based on the Filter criteria. There are a vast amount of options
that go beyond the scope of this article.
However, in this article, we will explore a not-well known or understood feature I’ll describe as “Multi-Leveling”. In other words, you can implement the multi-level filter technique that allows for multiple filter criteria to be combined into a single Filter.
In the sample Project shown below, “Thyme Street Bridge
Construction” consists of the construction 3 Piers comprised of Piles, Footers,
Columns and Caps. The Project is planned with 3 crews: a) a Pile Driving Crew;
B) a Footer Construction Crew; and C) a Carpenter Crew responsible for building
the Columns and Caps.
In this scenario, a reasonable CPM model for this Project would appear as shown below:
Now suppose we need to display
(or Filter) only the Cap construction for Piers 1 and Piers 3. Since the sample
set above is small, there are multiple options to accomplish this. However, for
the purposes of illustration, the most common solution would be to create 2
Filters. One filter to select only the Cap Construction, then another to select
Piers 1 and Piers 2. Once the 2 independent Filters are defined, the option to
“Show activities that match” is set to “All selected filters”.
The common solution approach
consists of:
Create a Filter to Select only Cap Construction as shown below:
The Filter shown above uses the “(All of the following)” option to select only activities containing the word “Cap”.
Create a Filter to Select Pier 1 or Pier 3 Construction as shown below:
The Filter shown above uses the “(Any of the following)” option to select only activities containing the word “Pier 1” or “Pier 3”.
Under the “Show activities that match” text, select the “All selected filters” option, then select both Filters created above as shown below:
The results of the 2 Filter selection criteria are correctly shown below:
The above solution is correct and operative, however, with the use of Multi-level Filtering, a better and more efficient solution can be constructed by combining both Filters into one Filter Criteria as shown below.
Create the first Filter criteria exactly as in Step 1 above as shown below:
Next, Include the next criteria similar to Step 2 above:
Add a third line using the “(Any of the following)” option similar to Step 2 above.
Add a fourth line, then enter the criteria “Where Activity Name contains Pier 1”. Make sure that Line 3 as shown below contains the “-“ symbol on the left indicating a second level is defined for the filter criteria. If the “-“ symbol is not shown, then click on the “Shift Right” arrow to create the second level. Notice also that the second “-“ symbol is indented indicating the second level criteria.
Add the fifth and final line, then enter the
criteria “Where Activity Name contains Pier 3”. Make sure line 5 begins with
“Or”. When done, select OK.
The results of the 1 Filter
selection criteria are correctly shown below:
This solution is more efficient since only 1 Filter used
eliminating the need to specify the “Show activities that match” option.
In conclusion, this simple example shows that the Filter option is more robust than what may initially appear. If necessary, additional levels can be added for more complicated Filters. The best way to improve your proficiency with Filters is to experiment with known results thereby better understanding its structure and behavior.
