Schedule Logic Techniques – Proactive Schedule Management

Though activity sequencing is a facet of Schedule Creation, building robust schedule logic is done as often as not to repair an existing schedule file, which is a facet of Schedule Maintenance. During the schedule creation process, schedule logic is reviewed frequently to as a means of coming to consensus about how the work will be performed.

This article will cover methods for finding and repairing common schedule logic problems in new and underway schedule files. This article assumes the Schedule Manager has good familiarity with the schedule file that is being created or reviewed. Hence, the discussion below will concentrate on fixing logic errors once they’ve been found.

Figure 1: Rebuilding schedule logic is a regular step when repairing a schedule.

Filling Logic Gaps

All generally accepted scheduling standards agree that each task or milestone should have at least one finish-to-start predecessor and one successor. Thus, spotting missing dependencies is one of the easiest steps to take, and provides a high return on investment for the time spent without in-depth schedule analysis. Complete schedule logic also improves the long-term robustness of the schedule. Whether the task is missing a predecessor or successor, the schedule manager need only identify what comes next or what happens first.

Figure 2: Two basic questions to identify missing dependencies.

When a task has no logical successor, the schedule manager should ask, “Can the project complete once this task is done?” If the answer is yes, the task’s successor is the project completion milestone. When a summary activity includes several parallel tasks, as depicted in Figure 3, tying the tasks to a milestone at the end of the activity is a convenient way to clean up loose ends. The milestone can then be tied to the next logical event.

Figure 3: Three activities which otherwise have no logical successor are anchored to a milestone.

Simplifying Complicated Logic

Some schedule management guides suggest testing a project file’s robustness by changing a task’s duration to see how the schedule will respond. This may be an interesting exercise for new schedule managers. However, for tasks which have counterintuitive or too many dependencies, the consensus answer is that the schedule will react badly. A better rule of thumb for testing the robustness of the schedule logic is to ask, whether the sequencing will make sense to a newcomer with no prior knowledge about the project.

Figure 4: A typical example of complicated schedule logic found in the field. These intradependencies probably made perfect sense to the schedule’s creator.

Summary Dependencies

Another high return on investment cleanup activity is eliminating summary activity dependencies. Figure 4 shows a project file with a summary activity successor and a summary activity predecessor. Fixing a summary activity successor relationship is often easy. Simply connect the successor task to the latest finishing task within the summary activity. (See Build New Data Model (10) in Figure 4.) If several tasks within the summary activity are occurring in parallel, a summary activity milestone can organize the low level dependencies. For the reasons discussed in Schedule Logic Principles, using milestones instead of summary activities to build dependency relationships builds far more robust dependency chains because the schedule logic is kept at the project schedule’s lowest possible level.

Figure 4’s summary activity predecessor relationship, Code Writing (12), can be handled in much the same way that the successor relationship was handled. This summary activity cannot start until the data model has been reviewed with stakeholders in line 11. Shifting the dependency from the summary activity corrects line 13’s. If multiple tasks are starting in parallel, inserting a milestone at the beginning of the summary activity again cleans up the low-level logic.

Finish-Finish, Start-Start, and Start-Finish Dependencies

Correcting atypical task dependencies usually takes the most effort. However, the starting questions remain the same: What happens first? What comes next? Build New Data Model (10) and Review Data Model with Stakeholders (11) have a Finish-Finish dependency. Why must these tasks finish simultaneously? One interpretation is that the project team will be reviewing the data model with the client as they are building it. This is a sensible approach for a project, and obviously reviewing the data model cannot complete before building the data model. However, the dangling logic confuses what needs to happen before the project team can begin reviewing the data model.

These two tasks happen to have similar durations. The schedule logic can be made more robust by assigning Write Design Documents (6) as each task’s predecessor and equalizing the durations. This logic simplification does necessitate a tradeoff. It is unlikely that reviewing the data model with stakeholders can start the same day the team begins to build. However, in practice this deviation from reality is far easier to manage than the review data model start date which hangs in the void. If this compromise is untenable, try breaking the larger task into smaller tasks as depicted in Figure 5.

Figure 5: Breaking the large Build New Data Model task into two separate tasks.

Lag

Lag is often a necessary element in a schedule, especially when describing time between tasks that is outside the project team’s control. However, the reason for adding lag to a dependency is often not contextually obvious. This can be addressed by using a custom text field for logic comments. The comments themselves do not need to be detailed to provide significant context. Some example logic comments include:

Customer Review Period
Machine Processing Time
Product Shipment and Delivery

When the reason for schedule lag is not obvious, the Schedule Manager should ask whether the lag is necessary. Dependency lags which do not represent a concrete and unavoidable pause in the sequence of events should be removed or replaced.

Figure 6: Some example improper uses of lag, the logic errors they cause, and one possible resolution.

Lag is not a baselined component of the schedule, but it is typically considered a fixed quantity since it represents work outside the project team’s control. Adjusting the lag between two tasks or milestones to compensate for a date change is at best inelegant. For example, if a document due to a customer for review is late and on the critical path, reducing the lag will short change the customer’s review period. And one can’t ask concrete to dry three days faster.

Figure 4 depicts a one-day negative lag between and Review Data Model with Stakeholders (11) and the code writing activities. As with the Build New Data Model (10) Finish-Finish dependency, the negative lag hides an assumption about when the task can start. Why can Code Database Interface (13) start before the data model is fully reviewed? Should the code writing tasks even be tied to the data modeling activities? Can code writing start earlier? Absent of additional information, this lag should be removed, pushing the code writing tasks’ finish date one day to the right. If a one-day shift during the planning stage is going to disrupt the project, the schedule is already too rigid and unlikely to complete on time.

Figure 7: Project schedule from Figure 4 with corrected schedule logic. Every line item that was affected by a single logic change is shaded with the same color. Note the cleaner horizontal traceability through the Gantt chart.

Constraint Dates

Constraint dates, like lag are occasionally necessary, but should be used only when no other schedule logic element can support the desired date. Date constraints, specifically Start No Earlier Than (SNET) constraints are also used by the schedule manager or the schedule management software to keep work not yet started ahead of the current schedule status date.

With rare exception,¹ there is no reason to use a date constraint other than an SNET constraint. Other constraints, especially hard constraints (Must Start On/Must Finish On), should be replaced by SNET constraints. Date constraints should also be justified with logic comments. Some typical date constraint logic comments include external dependencies, formal authorizations such as authorization to proceed, contractual obligations, deployment dates, and Agile sprint completion dates.

If a date constraint has no reasonable justification, it can be safely removed. Schedule managers should also watch for date constraints unintentionally set by the schedule management software.

Next Steps

Dependencies are not part of the schedule baseline. Schedule logic is not permanent, and like the schedule file itself, it is designed to serve project managers, not the other way around. To achieve the project’s objectives, the schedule manager will help team members adjust and adapt the schedule logic on a regular basis to understand what is possible and what is necessary. A basic understanding of schedule health checks and reviews will provide solid context for understanding how and why schedule dependencies and sequencing are changed over the life of the schedule to support the project team.