Out-of-Sequence Logic
Rescheduling activities may require adjusting network logic to explain why an activity did not start as planned, particularly if any of its successors have started or been completed. Out-of-sequence logic results from progress on an activity performed in a different order than originally planned such as
an activity starting before its F-S predecessor has finished;
an activity starting before its S-S predecessor has started; or
an activity finishing before its F-F predecessor has finished.
Out-of-sequence progress is common and should be expected, because some activity managers know they can safely start their activities, sometimes challenging their predecessor activity teams to speed up. When out-of-sequence progress occurs, managers and schedulers may choose to retain or override the existing network logic.
Retained Logic
In the case of retained logic, work on the activity that began out of sequence is stopped until its predecessor is completed. As much as possible of the original network logic is preserved because the remainder of the out-of-sequence activity is delayed until the predecessor finishes, to observe its original sequence logic.
Progress Override
In progress override, work on the activity that began out of sequence is permitted to continue, regardless of original predecessor logic. Actual progress in the field supersedes the plan logic, and work on the out-of-sequence activity continues. The predecessor and successor activities may now be executed in parallel, or the original logic on the activities is altered to model their new, more realistic, dependencies. Figure 45 shows the original plan for conducting activities for the interior finishes of the house construction project.
Figure 45: The Original Plan for Interior Finishing
For this example, we assume that the status date is December 30 and that “install tile in bathroom and kitchen” has completed on time. No progress was made on “install interior doors,” so its start date is rescheduled for December 31. However, its successor activity “install interior door, window, and baseboard trim” did start on December 29 and two carpenters accomplished 32 hours of work. This is illustrated in figure 46 by the status date (green vertical line) and gray bars that represent actual accomplished effort. If the schedule is statused according to retained logic, the remaining work for “install interior door, window, and baseboard trim” is deferred until the interior doors are installed. In figure 46, 2 days of actual duration are recorded for the “install interior door, window, and baseboard trim” activity, but the remaining duration is rescheduled to begin after “install interior doors” finishes. This start-stop-resume approach may not be an efficient way to install interior trim but it may be important given the reliance of the trimming activity on the installation of interior doors.
Figure 46: Retained Logic
If the schedule is statused according to progress override, the work for “install interior door, window, and baseboard trim” continues, regardless of the original plan’s logic. This concept is illustrated in figure 47. Two days of actual duration are recorded for the trimming activity, and the remaining duration is scheduled to occur in parallel with “install interior doors.” While the progress override accelerates the overall construction schedule by 1 working day, the time savings may not be feasible for several reasons. First, it assumes that “install interior door, window, and baseboard trim” does not depend on “install interior doors” finishing as the original plan dictated. Second, it assumes that resources are available to work on both the interior door installation and the interior trim installation. But both activities rely on two carpenters; the concurrent activities now require four carpenters on December 31 and January 2.
Figure 47: Progress Override
Finally, the installation of carpeting and wood flooring, originally scheduled to begin on January 8, is now scheduled to start on January 7. It may be unrealistic to assume that the flooring material and the floor installers will be available 1 day earlier than expected with less than a week’s notice. Additionally, the F-S logic between the “install interior doors” and “install door, window, and baseboard trim” activities should be reviewed and repaired. The successor logic of “install interior doors” should be linked to a new correct successor, perhaps “install carpeting and wood flooring.” If the logic is not corrected, “install interior doors” will, in effect, have no successor. It will therefore be able to slip to the end of the project without affecting the start date of any successive activity.
Retained logic and progress override are options in scheduling software that must be properly set before updating the status of the schedule. Each approach represents a different philosophy on how to manage unexpected developments in the program, and they can have vastly different effects on forecasted dates. Retained logic is a more conservative approach than progress override and is, in general, the preferred approach. As shown in figure 47, progress override may show better progress, but it may not result in a realistic plan.
It is recommended that the scheduler and activity leads examine each instance of out-of-sequence progress to determine correct responses case by case. While out-ofsequence activities are common, they should nonetheless be reported, and an analysis of the effect on key milestone dates is recommended before out-of-sequence activities are formally addressed. An out-of-sequence activity, despite the selection of “retained logic” or “progress override,” degrades the schedule and requires addressing. Regardless of how management wishes to proceed with the work related to the out-of-sequence activity, the logic relationship between activities should be repaired to show the order in which the activities were actually carried out. If left alone, out-of-sequence activities may complicate total float values and cause activities to become artificially critical. More importantly, out-of-sequence activities may represent risk or potential rework, because knowledge or products from the predecessor activity were not complete and available to the successor activity.