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 ( 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.



Updating the Project Schedule – Time Now and the Project Update Dialog in Microsoft Project

The absence of a dedicated time now or data date parameter in Microsoft Project makes regular schedule updates painfully difficult compared to other project scheduling software, but reliable and relatively quick updates are possible using the Project Update dialog.

Elements of Schedule Updates

Using modern project scheduling software, a schedule update that conforms to best-practices includes three key elements:

  1. Update Date/Time. Also called time now, the data date, status date, report date, or cutoff date.  This date/time value represents the temporal boundary between the past and future elements of the schedule.
  2. (Past) Progress.  I.e. historical documentation of actual activity dates, durations, work, costs, and sometimes physical completion.  All reported progress occurs before the Update Date/Time; that is, in the past.  Any non-actualized task dates (i.e. incomplete work) in the past are invalid.
  3. (Future) Forecast. I.e. remaining (not actualized) project work, costs, and activities that are uncompleted as of the update date/time and must therefore be executed in the future.  Any actualized task dates (i.e. completed work) in the future are invalid.

Generic Schedule Update Process

For a given update date/time, the past and future elements are defined through a two-step update process that endeavors to 1) update the status of each task to reflect the progress achieved (i.e. the completed work) as of the time now; and 2) update the overall status of the project by dynamically re-scheduling remaining work and forecasting the project completion in light of the current task status and sequential constraints.  The forecast provided by this second step must encompass all remaining work, including any work that has slipped from previously-established dates and remains incomplete.

The first step of the process – task status updating – typically involves a mix of techniques leading to actual start dates, actual finish dates, and actual (and remaining) durations.  In many projects, the accuracy of these actualized values  is of only minor note, as the next step – re-scheduling the remaining work after time now – is considered far more important for day to day project management.

The second step of the update process – overall project status update (i.e. dynamic re-scheduling of remaining work) – is performed automatically by most schedule calculation algorithms.  It typically requires nothing more from the user beyond resetting the time now date and clicking a function key.

Schedule Updates in Microsoft Project (MSP)

Unlike other modern project scheduling tools, MSP does not require any of the three elements named above, and the core updating functions seem focused on step 1, entering task progress (typically as duration %complete) against a static schedule.  In fact, the well-developed options for configuring and displaying progress lines suggest a persistent reliance on such static-schedule updating methods among influential MSP users.  [I first made progress lines about 35 years ago using paper bar charts hung on a corkboard, thumbtacks, and a weighted string.  For a couple months I had the daily job of inserting a thumbtack on each bar to reflect the reported task progress at the end of the previous shift, then winding the string around the tacks to create the progress line.  The line told everyone who was getting chewed out, but it said nothing about the current completion forecast or which work was most critical for the delivery.  This static view of schedule progress made sense – for a week at a time in our version of pull-planning – back in the days when re-calculating a ship-construction schedule was much more labor intensive than clicking F9 is today.]

Task Status Updating

[Nov’20 Edit:  I added this section after review with a colleague.]

MS Project provides a number of techniques for updating task status.  I’ve listed the main ones here, generally in order of preference for project control…

  • On a task-by-task basis, direct entry of actual dates, actual and remaining duration, and/or %Complete (which is definitely NOT preferred) in a user-customized task table, the default task Tracking Table, or the Task Details Form.
  • For one or more selected tasks, direct entry of actual dates, actual and remaining duration, and/or %Complete using the Update Tasks dialog;
  • For one or more selected tasks, clicking buttons on the Task ribbon with underlying wizards/scripts to enter a specific %Complete (0%, 25%, 50%, 75%, or 100%) or to Mark on Track (which automatically actualizes all progress as scheduled up to the project’s Status Date);
  • For selected tasks or for all tasks in the project, using the upper portion of the Update Project dialog to “Update work as complete through:” any user-selected date.  (This is essentially the same as Mark on Track, automatically actualizing all progress as scheduled up to the user-selected date, but defaulting to all tasks);
  • For all tasks in the project, direct integration with timesheet entry systems (for actual start and actual work, on cloud-resident or server-resident projects only).

The program’s response to these inputs can vary widely, depending on overall program settings, individual task characteristics, and the order and timing of the entries.  As a result, the methods for updating task status seem to vary widely between industries and even between competent professionals in the same industry.  Some even use progress lines, though not for the same purpose I described earlier.  The end objective is similar for all methods, however: the designation of specific tasks and parts of tasks as being completed (i.e. actualized), and therefore in the past.

Project Status Updating

The project status update first requires that all uncompleted tasks (and parts of tasks) are dynamically rescheduled to take place in the future. In a major difference from other tools, MSP does not directly incorporate a dedicated time now parameter in the schedule network calculations – like the data date in Oracle P6 and other software or the report date in Elecosoft Powerproject.  Instead, the forward-pass calculations always begin at the project start, and the restraining effects of time now are achieved only by imposing external start-no-earlier-than (SNET) date constraints (for un-started tasks) or by delaying Resume dates (the start of the remaining duration for in-progress tasks.)

[Nov’20 Edit:  I added the next paragraph after review with a colleague.]

In practice, some experienced MS Project schedulers explicitly effect these modifications on a task-by-task basis as part of the task status update above.  Thus, when a task that should have had progress instead has none, the scheduler manually imposes a new SNET constraint either on the status date or on some other (later) promised date.  Similarly, the actual and remaining durations of tasks with partial progress may be manipulated to straddle the status date.  This manipulation can be done either manually or automatically,  with the latter accomplished by entering task %Complete while the move start of… and move end of… advanced calculation options are enabled.  (As a rule, however, any entry of task %Complete is normally to be avoided, and these advanced options can be more trouble than they are worth.)

MSP’s Update Project Dialog (2)

When the necessary constraints and Resume-delays on incomplete work are not imposed during individual task updating, the lower part of the Update Project dialog can be used on selected tasks.  With “Reschedule uncompleted work to start after…”, the program compares the existing schedule Start/Resume dates for each task (in the selection or in the whole project, as indicated) to the update date that the user has specified.  If the task’s Start/Resume date is a) not actualized and b) earlier than the specified date, then a SNET constraint or Resume-delay is imposed.  (The latter action will be taken only if the schedule option for split-in-progress tasks is checked, the default setting.)  The next time the schedule is re-calculated, the new constraints will be imposed on the early dates, thereby simulating the effects of an explicit time now.

Issues with Update Project

  1. Although the Current Date or the project’s Status Date (if present) are pre-populated in the dialog, the Update Date is not limited. The user may choose any other date for re-scheduling any task or group of tasks.  Thus, the schedule effect of a singular time now is susceptible to user interference, intended or not.
  2. Since MSP only allows the use of a single constraint for each task, the tool fails to re-schedule tasks with conflicting constraints. A SNET constraint with an earlier (non-conflicting) date will be replaced, but if a task with a late start, late finish, or early finish constraint is delayed, the new SNET constraint can’t be applied.  The user must then either abandon the existing constraint or impose a delay using new synthetic logic.
  3. By default, the actions of the dialog are applied to the “Entire project,” and changing the option to “Selected tasks” only, if desired, must be repeated each time the dialog is opened. Using the default option with Reschedule uncompleted work to start after… typically imposes superfluous SNET constraints on tasks whose logical predecessors are similarly delayed.
  4. Since reliance on external date constraints is generally considered poor practice, the SNET constraints imposed during normal schedule updating in MSP may be flagged by schedule quality monitors. Users are tempted to evade such flags by introducing synthetic logic – especially on high-float tasks that are “riding the data date.”
  5. The numerous SNET constraints imposed through multiple schedule update periods need to be monitored and removed (after actualization) if the original project plan (i.e. logic and constraints) is to be maintained.
  6. Reschedule uncompleted work to start after… is not compatible with resource-leveled schedules. All resource leveling delays must be cleared before the tool is run, and the leveler should be called again only after the subsequent recalculation of the schedule network.

For a more comprehensive look at schedule updating in MSP, P6, and Elecosoft PowerProject, have a look at Paul Eastwood Harris’s detailed paper on the subject.