In MSP, a “backward scheduling” mode – sometimes called backward planning, reverse scheduling, or reverse planning – can be invoked by scheduling the project from its finish rather than its start. In the traditional language of Critical Path Method scheduling, it’s most simply described as a Late Dates schedule. Backward planning is useful in several non-standard methodologies, including Critical Chain Project Management and the “Pull Planning” aspects of the Last Planner System.
The Mechanics of Backward Scheduling
When specified for the active project, this mode essentially does the following:
- Sets the default constraint type for all new tasks to As Late As Possible.
- Re-sets the constraint type for all existing Summary tasks to As Late As Possible.
- [Users choosing this mode in the middle of schedule development must manually re-set the constraint type for all existing non-Summary tasks to As Late As Possible.]
- Automatically sets “No Later Than” constraints when dates are manually entered into the Start or Finish fields of tasks. [Such date entry in forward scheduling mode leads to “No Earlier Than” constraints, so users choosing this mode in the middle of schedule development should manually review, validate, and potentially re-set any previously-entered date constraints.]
- Performs the network scheduling calculations in reverse order, with the reflection point occurring at the project start rather than the project finish. I.e. the Project Start Date (not the Finish, which is user-input) is determined by the logic.
- Sets the “Start” and “Finish” of automatically-scheduled tasks to their Late Dates rather than their Early Dates. (This is the most important part.)
- Finally, the resource leveling engine resolves resource over-allocations by accelerating higher priority tasks from late dates rather than delaying lower priority tasks from early dates. Thus, entries in the “leveling delay” field are negative. This behavior creates a minor complication regarding use of Priority = 1000. Just as in forward scheduling, a task with Priority=1000 is always exempted from any leveling action. In backward scheduling, this means that Priority values of 1000 and 0 are essentially equivalent when considered in the leveling decisions. The highest effective Priority for controlling leveling behavior then becomes 999, not 1000.
Logic relationships used in backward scheduling still have exactly the same meanings that they do in forward scheduling. A Finish-to-Start relationship still means that the two tasks are logically connected such that the successor may not start before the predecessor finishes, and the rarely-applicable, Start-to-Finish relationship still indicates that it is impossible for the successor to finish before the predecessor starts. Some users seem to think that backward scheduling involves reversal of these two relationships in particular, but that’s not consistent with the rest of the backward scheduling mode. Unfortunately, mixing of the two approaches seems to continue, though this typically amounts to invalid date manipulation in my view.
In normal (i.e. forward) scheduling, a task with an “As Late as Possible” constraint has the dubious distinction of corrupting its entire chain of successors – driving all of them to the critical path. There are very few legitimate applications for this constraint. In backward scheduling, the “As Soon as Possible” constraint plays a similar role, corrupting its chain of predecessors. It needs to be avoided in backward scheduling.
When the logic network is well constructed – and complicating factors like multiple calendars, (Early) constraints, and resource leveling are avoided – then the Critical Path may be reasonably identified by Total Slack = 0. Other methods of driving logic analysis must be modified, however.
Driving Logic Analysis
Under Backward Scheduling, any slack/float of a task exists on the side towards its predecessors, i.e. to its left on a bar chart. A driving relationship exists when a successor prevents a predecessor from being scheduled any later than it is. This means that there are Driving Successors and Driven Predecessors. Consequently, the Longest Path in a backward scheduled project is the Driving (Successor) Path from the Project’s Start. Obviously, time does not pass in reverse, so a backward scheduling method seems pointless if the latest allowable Project Start Date has already been passed – e.g. the project is in progress.
MSP includes two built-in methods for reviewing and analyzing driving logic: the Task Inspector and the Task Paths bar styles. As I wrote in this article a few years ago, I’ve found these tools to be unreliable in complex real-world project schedules. Under backward scheduling, they are essentially useless and/or misleading.
To start with, Task Inspector simply doesn’t work with backward scheduling. Opening TI on a backward scheduled project yields the following message: This project is set to Schedule from Finish. We are unable to provide scheduling information.
Also under backward scheduling, the “Driving Predecessors” and “Driven Successors” bar styles are still derived from Early Dates, as they are in Forward Scheduling. This makes them essentially useless for assessing the controlling logic of the displayed (Late Dates) schedule. Consider the example below, where all four Task Path bar styles have been imposed, and Task 11 – A2 Structures – is selected. (The automatic “Slack” bar style is also imposed, but it is invisible since Free Slack – formally defined by Early dates alone – is uniformly zero.)
The selected task is in fact driving/controlling the displayed dates of both of its predecessors, but only one of them displays the correct bar style (the one that was the driving predecessor during the forward pass). Of Task 11’s four successors, only the first (Task 13 – A2 Electrical) is directly driving/controlling Task 11’s schedule. The tasks for two of the remaining three successor relationships are incorrectly highlighted, while the third (Task 14) is correctly highlighted only because it is driving/controlling Task 13 – a case of redundant logic. (All four successors were driven successors during the forward pass.) Thus in a backward scheduled project, the Task Path bar styles for Driving and Driven dependencies are meaningful (or “correct”) ONLY along the Longest/Critical path of the project, where Early dates and Late dates coincide.
BPC Logic Filter – my company’s Add-In for logic analysis of MSP schedules – identifies driving logic based on relationship free float, which we often call “relative float.” In BPC Logic Filter, the Longest Path and near-longest paths of simple, backward-scheduled projects can be found using the Task Logic Tracer, starting from the project start milestone and using appropriate settings (i.e. driving relationships in successor direction). As illustrated in the example project, this is fairly trivial since the results are 100% aligned with Total Slack.
Other driving logic paths (not on the Critical Path) are not so trivial but are easily addressed using BPC Logic Filter, provided that the impact of multiple calendars is minimal.
Precision analysis of more complex, backward-scheduled projects would require some modest modifications to the algorithms. If any BPC Logic Filter users see a need for such an improvement, please let me know in the comments, and I’ll pass it along.