“Near Longest Path”

Multiple Critical Paths – Revisited with BPC Logic Filter

While writing an article on Multiple Critical Paths a few years ago, I knew that BPC Logic Filter (our add-in for Microsoft Project) could easily identify multiple critical paths (and near-critical paths) in any project schedule, but we needed to analyze key milestones one at a time. In most cases I think that’s still the best approach to understanding the factors that drive (and may delay) key project deliverables. Nevertheless, the latest build of the software (1.5.5.13) includes a new setting that facilitates simultaneous analysis and display of the critical paths to multiple milestones in a project or program schedule.

The setting – Group Results by Selected Task – is found on the Tracing Preferences tab of the software settings, and we enabled it as part of the initial distribution of the build. We hope that at least a couple users have been pleasantly surprised.

This short article provides a couple illustrations of the feature in action.

First, here is the simple example project from the previous article. The project comprises six “phases” of inter-related tasks in a Microsoft Project schedule, now displayed using MSP 2016 rather than MSP 2010 as before. The project has no deadlines or constraints, and MSP designates critical tasks (red bars in the chart) based on total slack (TS<=0).

In the previous article, I illustrated – using MSP and Oracle P6 – several generic techniques to identify the unique critical path for each of the six phase completion milestone in the project. I also used BPC Logic Filter to graphically illustrate the critical- and near-critical paths for the Phase 1 completion milestone, displayed within the context of the overall project (and repeated here in MSP 2016).

Going back to the original project, we can now run the task logic tracer with all six phase-completion milestones selected. The Standard Edition of BPC Logic Filter then allows us to select driving-path predecessors and to re-sort the results to show logical branches (i.e. paths).

The result is a grouped view displaying the driving predecessor path to each of the six phase-completion milestones.

Due to intersecting logic, some tasks are on the driving/critical path for more than one completion milestone, but the Gantt chart only allows them to be displayed once. The task logic tracer displays such tasks together with the driven milestone that is encountered first in the original task selection. Thus, while tasks 1A, 4A, and 4B are critical for the overall project and for the phase-6 completion, they are displayed with the phase 4 completion milestone – for which they are also driving/critical – because that milestone was encountered first in the user’s selection. As a consequence, re-sorting the tasks in the overall project can alter the apparent driving paths for key delivery milestones when intersecting logic is present.

The same caveat applies when considering near-driving/critical paths for multiple key milestones in the same project, along with an added condition that a non-driving task will be included with whichever key milestone it is nearest to driving. To illustrate, we have re-run the previous analysis while considering path relative float, and we’ve decided to re-color bars to clarify results.

The resulting output is like the earlier one, but now including annotated bars and tasks whose path relative float is above zero (i.e. non-driving).

From the earlier article, we already know that task 1A is a non-driving path predecessor of the phase-1 completion milestone, 2 days from driving that milestone. It is nearer to driving (and is in fact driving) the phase-4 completion, however, so that is where it is shown.

As we’ve seen, it can be difficult to differentiate the critical paths to multiple completion milestones in a complex project with lots of intersecting logic paths. When a project or program includes multiple completion phases that are not closely related, however, the output is straightforward. A good example of this case occurs when multiple unrelated subprojects are combined into a linked master project for reporting purposes. Here I’ve used the New Window dialog to temporarily combine three simple projects into a temporary master. Then I have applied a filter to show only the key completion milestones for the three subprojects. Finally. I’ve run the task logic tracer with all the visible tasks selected. A Pro Edition of the tool is required to analyze linked subprojects, and I’ve limited the relative float analysis to keep the resulting output small.

The resulting layout clearly depicts the critical/driving- and near-critical/driving paths for each subproject completion milestone. As usual – for BPC Logic Filter – the definitions of critical/driving logic paths do not rely on the total slack, which is not reliable in many modern project schedules.

AACE International Annual Meeting 2020

Last month marked my second attendance at an Annual meeting of AACE International (formally Association for the Advancement of Cost Engineering). The Covid-19 Pandemic forced a change of venue from Chicago to Virtual/Online, with overall good results. Most of the technical presentations were pre-recorded for viewing at leisure. There was also a live track including keynotes, selected technical presentations, and business meetings. There were attempts to facilitate online “networking” and other informal “events”, but I missed those.

Earlier in the year, I co-authored a paper (with Patrick M. Kelly) for presentation at the meeting: (PS-3496) Interpreting Logic Paths in Multi-Calendar Project Schedules. It’s essentially a deep-dive into the Multiple Float Path calculation in Oracle Primavera P6 project scheduling software, expanding on (and in a few cases contradicting) my earlier blog articles, and Patrick’s paper, on the subject. A slightly revised version of the paper is hosted on our website. Pre-recording the presentation (as a narrated PowerPoint show) involved quite a bit more effort than a live presentation would have; I hope to become more efficient at it with additional practice.

The presentation (all 70+ minutes of it) and the paper are included in the Transactions bundle for registered attendees of the meeting. They are also available for purchase by non-attendees (including a training certificate after viewing the presentation) at the AACE store. I think the price is $25 for members of AACE and $30 for non-members.

I also got “elected” to the board of the Planning and Scheduling Subcommittee, and I look forward to taking over the coordination of our Recommended Practices from our rising Chairman, Jessica Colbert, for the next year.

Video – Analyze the Near-Longest Paths in Microsoft Project using BPC Logic Filter

In the presence of Deadlines, Constraints, variable Calendars, and resource leveling, Total Slack becomes unreliable as an indicator of the Critical Path (or of nearness to the Critical Path). For projects where the project completion is designated by the last task in the schedule, I use the Near Longest Path Filter to keep an eye on next week’s concerns….

See also a related blog entry: Tracing Near Longest Paths with BPC Logic Filter

Video – Logic Tracing Example in Microsoft Project

Here is a video showing BPC Logic Filter in action, and repeating the same general themes as A Logic Tracing Example in Microsoft Project.

Tracing Near Longest Paths with BPC Logic Filter

This article highlights the creation of a new targeted report from BPC Logic Filter to identify the “Near Longest Paths” of a project.

While BPC Logic Filter was originally developed as a pure logic tracer, I added a few targeted reports early on to reflect some specific needs, including the “Longest Path Filter” and the “Local Network Filter.” This article highlights the creation of a new targeted report to identify the “Near Longest Paths” of a project.

Often, when presented with a new project schedule in Microsoft Project, my first step (in concert with a logic health check) has been to run a Longest Path Filter analysis using BPC Logic Filter. This report quickly and clearly identifies the driving path to project completion. While the resulting filtered task list is useful for reporting, it rarely satisfies the needs of a serious analysis. The second step, therefore, is to identify the associated near-longest-paths of the project by running a “Task Logic Tracer” predecessor analysis – with a positive relative float limit – for the project completion task. The result is a clear description of the driving and near-driving paths to project completion. The latest release of BPC Logic Filter adds a specific command to combine these two actions and generate a single “Near Longest Path Filter” for the project.

The mechanics are pretty simple. As usual – with a Gantt view active in a project that contains logic – just open the Add-Ins ribbon [changed to the BPC ribbon in subsequent versions] and click on the button for “Near Longest Path Filter.”

The add-in will initialize, and the user is given a choice of modifying the default analysis parameters. Some of the parameters are pre-set and can’t be changed here. The key parameter for a formal Near-Longest-Path analysis is the Relative Float Limit, highlighted below. Any related task with a Path Relative Float that is less than the specified limit will be included in the filter; all others will be ignored and considered unrelated. The default value is 100 days away from the driving/longest path (which can be changed in the Settings).

The standard output for a simple project (using the parameters selected above) is provided here. Selecting “Re-Color Bars” instructs the add-in to generate the custom output shown, including the header, the legend, and five different bar colors depending on proximity to the Longest Path. Thresholds for applying these bar colors can be manually adjusted in the program settings or, if desired, automatically adjusted by the add-in.

Here’s an alternate view showing the Near Longest Paths in-line in the context of an existing Outline/WBS organization. In this analysis I reduced the Relative Float Limit from 100 to 20 days, and the three tasks at the bottom of the earlier figure were ignored. Here they are given a green “BPC Unrelated Task” bar.

While I’ve always hated redundant work, this particular improvement to BPC Logic Filter was kick-started by my recent review of the draft of “Analyzing Near-Critical Paths,” a pending Recommended Practice from AACE International. The new draft recommended practice is based largely on the previously-published (2010) Recommended Practice 49R-06 – Identifying the Critical Path. According to both documents, Critical- and Near-Critical paths may be identified on the basis of total float/slack thresholds (in the absence of variable calendars, constraints, or other complicating factors) and – when total float/slack does not suffice – “closeness to the longest path.” For the latter cases, 49R-06 suggests two methods of analysis:

Longest Path Value – a metric that appears similar to Path Relative Float (in BPC Logic Filter) for the project completion task. This metric has been applied as an add-on to Oracle Primavera scheduling tools: See Ron Winter’s Schedule Analyzer.
Multiple Float Path analysis. Like the Longest Path Value, Multiple Float Path analysis is primarily associated with Oracle’s Primavera scheduling tools – it is presented as an advanced scheduling option in P6. As I’ve noted in Beyond the Critical Path – multiple float path analysis indicates closeness to the longest path without explicitly measuring and presenting it. Detailed examination of the results, including relationship free floats, is necessary to determine the apparent relative float of each activity.

From its start, BPC Logic Filter has supported a similar analysis for Microsoft Project schedules through its Path Relative Float metric, Multiple-Float-Paths views, and other reporting. The new “Near Longest Path Filter” offers a single-step approach to identifying and analyzing near-critical paths in the presence of variable calendars, constraints, and other complicating factors – when Total Slack becomes unreliable as an indicator of logical significance.