Though activity sequencing is a facet of Schedule Creation, building robust schedule logic is often done to repair an existing schedule file, which is a facet of Schedule Maintenance.
Even during the schedule creation process, schedule logic must be reviewed to ensure that the activity sequencing reflects how the work will be performed.
This article will cover methods for finding and repairing common schedule logic problems in new and in-progress 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.
Filling Logic Gaps
Since generally accepted standards declare that each task or milestone should have at least one predecessor and one successor, spotting missing dependencies is one of the easiest steps to take, and provides significant dividends for the time required. Complete schedule logic also improves the quality of later robustness checks. Filling in missing schedule logic does not necessitate in-depth analysis. Whether the task is missing a predecessor or successor, the schedule manager need only identify what comes next or what happens first.
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.
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.
After filling in missing dependencies, the second-best return on investment when cleaning up schedule logic is the elimination of summary activity dependencies. Figure 4 shows a project file with a summary activity successor and a summary activity predecessor. Fixing the successor relationship in most cases is easy. Build New Data Model (10) is dependent on Requirements Analysis and Design (3) completing. Since all tasks in this activity are sequenced, the simple fix is to tie the successor to the last task in the activity, Write Design Documents (6). If the three tasks were being performed in parallel, such as in Figure 3, Build New Data Model (10) could be tied to a finish milestone. Using milestones instead of summary activities to build dependency relationships is far simpler for critical path traceability, and far more robust if the schedule’s outline structure gets rearranged.
The summary activity predecessor relationship can be handled in much the same way that the successor relationship was handled. (The negative lag will be discussed below.) Code Writing (12) activities cannot start until the data model has been reviewed with stakeholders (11). Shifting the dependency from the summary activity to the first task inside the summary corrects the dangling logic in Figure 4. If multiple tasks are starting in parallel, simply tie the predecessor to each parallel task, or for neatness to an activity kickoff milestone.
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, it’s not clear what needs to happen before the project team can begin reviewing the data model with their stakeholders.
These two activities happen to have similar durations. The schedule logic can be made more robust by assigning the same predecessor to each activity, (Write Design Documents (6) after correcting the summary activity dependency) and setting the durations equal. Taking this step forces the schedule manager to make a tradeoff. It is unlikely that the team member building the new data model will start reviewing it with stakeholders the same day they begin building it. However, this deviation from reality is far easier to mitigate than the review data model start date which hangs in the void.
Suppose building the data model was expected to take far longer than reviewing the data model with stakeholders. In this case, the tradeoff does not make sense. But the hanging logic is still problematic for effective schedule analysis. What is the best choice in this scenario?
The long duration of the data model task suggests that the team member is going to draft the new data model in whole or in part before showing it to stakeholders. If that’s the case, the team member’s task should be broken into two pieces. This extra detail, depicted in Figure 5, clarifies the plan of attack for the team member building the data model. It also sets expectations for stakeholders wondering what they will be expected to review starting in mid-February. In the event of a delay, it is easier for all sides to understand the cause for the delay based on what’s in the schedule file.
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 justified. Dependency lags which do not represent a concrete and unavoidable pause in the sequence of events should be removed or replaced. There are a number of reasons why positive or negative lag may be misused.
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.
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.
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[mfn]One of these exceptions is backwards pass planning or pejoratively, procrastination planning. This schedule creation strategy fixes a project finish date and plans all project activities backwards from the finish date. Using this strategy, the flow of schedule logic is reversed. The Project Complete milestone has a Finish No Later Than constraint, and all tasks are planned to start late as possible, rather than as soon as possible.[/mfn], 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 the following.
- External Dependency
- Authorization to Proceed
- Deployment Date (or another critical milestone)
- Agile Sprint Completion Date
If a date constraint has no reasonable justification, it can be safely removed. Schedule managers should also watch for date constraints unintendedly set by the schedule management software.
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.