Schedule Logic Principles – Proactive Schedule Management

Schedule management software applications such as Microsoft Project and Oracle Primavera allow a variety of ways to logically link tasks, summary activities, and milestones. However, the breadth of options makes it possible for schedule managers to confuse complexity for sophistication. In practice, complicated schedule logic creates schedule files that are less robust, less adaptable to change, more likely to become untenable, and more likely to hide driving tasks.

As covered in Schedule Logic Fundamentals, predecessors and successors defines how two tasks or milestones relate to each other in the flow of the project. Lag and constraint dates describe project events which can’t be cleanly described by normal dependencies and resource leveling. This article will discuss how simplified schedule logic supports the broadly accepted best practices for what is commonly referred to as activity sequencing.¹ It will then cover examples demonstrating why more complicated logic elements used for convenience, can impact a schedule’s long-term reliability.

Simplicity Builds Robustness

The most important guidance for building schedule logic is to keep the dependency relationships simple. Sophisticated dependencies are strong temptations when building a new project file, because they allow the person building the schedule to make shortcuts in fleshing out their reasoning. For example, if Tasks A and B need to finish at the same time, use a Finish-Finish dependency. However, the reasoning that went into building complicated dependency relationships is often forgotten by the middle of a project, especially if the person managing the schedule is not the person who planned the schedule.

Simplicity also makes project schedules more robust in the long run. A schedule file that is intended to support a project over a long lifetime must have schedule logic capable of withstanding the dynamic and uncertain environment that defines most projects. Schedule files with complex intradependencies are prone to unpredictable behavior and broken schedule logic. The more sophisticated dependencies, lag and date constraints offer a shortcut to the otherwise tedious process of building out schedule logic. However, these shortcuts come at the expense of robustness.

Dependencies

There is broad agreement amongst the most commonly recognized schedule management handbooks that all tasks² and milestones should have at least one predecessor and at least one successor to support critical path analysis. Beneath this “means to an end” explanation lays an important concept. All tasks and milestones in a project are dependent on at least one event preceding it, and another event succeeding it before the project can complete.

Applying this concept throughout the schedule file ensures that no tasks have dangling logic which begs project teams to ask, “What comes next?” or “Are we done?”

What Dependency Types Convey

When introducing the concept of network diagrams, project management textbooks will depict a network diagram built solely with Finish-Start dependencies, like those depicted in Figure 1. Why are Finish-Start dependencies more logically intuitive, and the easiest task relationships for us to understand?

Figure 2: No successor task on the bottom row has a start date that is directly determined by another task’s finish date.

Part of the answer is that we have more practical life experience with Finish-Start dependencies. From grade school we learn about step-by-step instructions, alongside sequences of letters and sequences of numbers. In a schedule file, the start date of the Finish-Start successor task is directly defined by the previous task’s completion. We understand what we must finish before starting the next task.

Finish-Finish and Start-Finish dependencies work backwards from a finish date to indirectly predict the next task’s start date. We must know something about the preceding task’s duration to know when the subsequent task should start. Start-Start dependencies are more logically robust, but still beg the question, what must finish before the next task can start?

Summary Activity Dependencies

Nearly every large project schedule is supported by an outline structure grouping related tasks and milestones. This grouping often mirrors the project’s work breakdown structure, or it may some other organizational purpose. Summary activities also aid in creating reports such as summary Gantt charts. Following best practices, summary activities have no work or resource assignments of their own, have date constraints, or logic dependencies. Linking summary activities superficially appears to be convenient. In practice, adding dependencies to summary activities creates strong potential for unnecessary and unintended logic errors.

Linking summary activities to other line items creates competing or mutually exclusive logic branches in a dependency chain. For rough analogy, consider driving across Pennsylvania when suddenly the turn-by-turn directions instruct you to navigate from Altoona to Harrisburg. Figure 3’s break in detail may not derail longtime residents who know the local roads. But project schedules, like driving directions, are meant to aid trailblazers. Summary level connections force assumptions which lead to confusion and avoidable errors down the road. Taking the time to work through dependencies at lowest level of detail guarantees greater clarity in the middle of the project and simplifies revising the schedule when plans change.

Figure 3: Imagine the disruption navigation devices would cause if they suddenly shifted from turn-by-turn directions to pointing drivers to the next major city.

Summary activities are not substantive on their own. Like a folder or a computer directory, summary activities’ material properties, including duration, effort, start and finish dates, are defined exclusively by the subtasks they enclose. Setting dependencies or date constraints on a summary activity attempts to link a real event such as drafting a document, to an abstraction such as a requirements lifecycle phase.

Figure 4: Gantt Chart showing tasks, summary activities and a milestone. Note that Write Design Documents (6) is on the critical path, even though it has no successor dependency.

Figure 4 shows an example of how summary activity logic complicates traceability. Consider the task Write Design Documents (6) in Figure 4. This task has no follow-on dependencies, so Tom need not worry if the task runs late. Unfortunately, that’s not true. Build New Data Model (10) cannot begin until the entire Requirements Analysis and Design (3) activity completes. Tom cannot see at the lowest level that postponing the completion of the design documents will delay Ian’s construction of the new data model. But that may not be true either. Ian doesn’t know what specifically he needs to get started on the new data model. Maybe he needs the design documents. Or maybe he only needs the functional specifications.

Straightening the critical path in Figure 4 is relatively straight forward. In a large project schedule, predecessor/successor relationships between tasks and summary activities can cause erratic date changes in distant and seemingly unconnected parts of the schedule.

Lag

Waiting for concrete to dry and the time a client requires to review a document are outside the project’s control. Such activity gaps are represented by lag. Lag is also used as a crutch to stagger tasks running partially in parallel. Like the Finish-Finish dependency, this use of lag offers managers a shortcut when building out their schedule logic.

This use of lag also embeds unstated assumptions into the schedule file clouding the project team’s understanding of what needs to happen. The technical specifications on the left side of Figure 5, declare that the reviewer should begin reviewing technical specifications three days prior to the writer’s completion date. The negative lag assumes that the writer makes consistent, highly predictable progress during the entire effort. This assumption may be reasonable for an experienced writer performing well understood tasks. But why is the handoff based on a measure time instead rather than specific work accomplished? If the writer gets delayed, the predicted handoff date is unlikely to make sense compared to the lag time.

Figure 5: The successor task’s start date is based on an assumption about the predecessor’s duration or progress.

In Figure 5’s other example, setting up the computer lab has a lag based on progress. Progress lag can be conceptually less abstract than duration lag. A sixty percent completion lag between setting up computer equipment and connecting wires may suggest the installers will begin connecting equipment when the desks and desktop PCs are placed. However, percent complete is often arbitrary and difficult to substantiate measure of progress. Despite the PCs being on backorder, the installers may safely claim 60% progress for setting up the desks, chairs, monitors, keyboards, and mice. The schedule logic provides no explanation why connecting power and networking is impeded.

While the examples depicted in Figure 5 are straightforward to resolve, issues with lag in the middle of a large complex project can be laborious, requiring consequential revisions in how current and upcoming work is depicted.

Constraint Dates

Like Finish-to-Finish and Start-to-Start dependencies, Constraint dates can be misused to shortcut well thought out schedule logic. There are two ways in which constraint dates may harm a schedule’s reliability. First, a date constraint may artificially set the start date of a task, or sequence of tasks, delaying work which otherwise could start. Second, constraints known as hard constraints can pin a task to an unrealistic start or finish date which ultimately breaks the schedule logic.

Figure 6: Date constraints appear to be inhibiting the logical start of interface testing and project completion.

Constraint Overreliance

Figure 6 depicts the testing phase of a software project that will soon complete. Write Test Cases is tied to completing the design of a database, not shown above. This task can start as soon as its predecessor completes. However, a date constraint creates a nearly one-week gap between the completion of Write Test Cases and the start of Test Interface in Production Environment.

Why is the start of the Test Interface task postponed? Was Write Test Cases padded with slack to ensure it would finish on time? Is the testing environment not available until March 15^th? Though there could be several good reasons for the delay, the lack of explanation in the schedule suggests that the logic was not well thought out. Release Software and Update Release Notes makes a similar mistake by using a constraint date but no predecessor relationship. Releases and other major events must often start or end by a specific date to minimize a disruption of normal operations. However, the lack of a dependency between testing and the release is likely to lead to a break in schedule logic, like the one depicted in Figure 7.

Hard Constraints

Hard constraints are dangerous. They are capable of divorcing schedule logic from reality. In Figure 6, the project completion date is given a hard deadline of April 7^th. However, in Figure 7 the delay to testing creates an impossible scenario. The project must finish on April 7^th. But testing won’t complete until April 11^th. Which absolute wins out? Will the conflict even be noticed before it becomes a crisis?

Figure 7: A delay to testing causes two breaks in the schedule logic. The software will be released and the project will be complete before testing finishes.

If project leadership takes only a cursory glance at the major milestones, they will miss the issue. Meanwhile, if the test team has tunnel vision for only their work they may miss that their work will delay the project.

Note on Resources and Task Dependencies

A common mistake which people succumb to when building a schedule file is to use task dependencies to balance workloads and resource availability. This well-intentioned practice commonly builds artificial delays into the schedule. When circumstances delay portions of a project schedule, managers commonly shift priorities to other activities. Since predecessor/successor relationships cannot distinguish between a task dependency and a resource constraint, false dependencies make reprioritizing work more difficult.

Figure 8: Assuming these draft project documents have no intradependencies, sequencing these tasks (left) because there is only one writer is a mistake. Distributing the team member’s time evenly across all for documents (middle) or resource leveling the project (right) will produce a more robust schedule.

Additionally, if the project team decides to hire more resources, the schedule logic prevents sequenced work from taking place in parallel. Balancing (or leveling) workloads when resources are scarce is best done using the Work Equation. Resource leveling and the three possible ways to plan the tasks in Figure 8 will be discussed in later articles.

Next Steps

This article has covered at a conceptual level, why simple logic elements improve the schedule’s robustness. The next step is to understand how to put concepts of building simple schedule logic into practice. Schedule Logic Techniques will cover how to correct common schedule logic mistakes once they are identified.