Microsoft Project and other schedule management software applications allow a variety of ways to logically link tasks, 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 Understanding Dependencies and Sequencing, schedule logic consists of three types of elements:
- Dependencies between any two tasks or milestones
- Lag associated with a dependency
- Constraint dates associated with a task or a milestone
This article will discuss how simplified schedule logic supports the broadly accepted best practices for what is commonly referred to as Activity Sequencing.[mfn]
The following guides are recommended reading for a comprehensive overview of the best practices for building schedule logic.
US Government Accountability Office, GAO Schedule Assessment Guide. https://www.gao.gov/products/GAO-16-89G, December 2015
Project Management Institute, A Guide to the Project Management Body of Knowledge. https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/sixth-edition, September 2017
Defense Contract Management Agency, DCMA 14-Point Schedule Assessment. http://www.dcma.mil, January 2011
International Project Management Association, Individual Competence Baseline for Project, Programme & Portfolio Management. http://products.ipma.world/ipma-product/icb, 2015[/mfn] It will then cover examples demonstrating why more complicated logic elements are used as a convenience, and their impact to a schedule’s 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.
There is broad agreement amongst the most commonly recognized schedule management handbooks that all tasks[mfn]Many guides use the terms “tasks” and “activities” interchangeably. For the purposes of this article, a “task” is any line item in a schedule file where work is being performed by at least one individual. A “summary activity” is a line item in the schedule file that provides outline structure for sub-tasks but does not itself represent work being performed. Milestones are zero-duration line items that represent the beginning or end of an event.[/mfn] 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.
Many guides use the terms “tasks” and “activities” interchangeably. For the purposes of this article, a “task” is any line item in a schedule file where work is being performed by at least one individual. A “summary activity” is a line item in the schedule file that provides outline structure for sub-tasks but does not itself represent work being performed. Milestones are zero-duration line items that represent the beginning or end of an event.
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?
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. The outline structure sensibly organizes the work to be performed, gives the work breakdown structure prominence in the schedule file, and aids in creating reports such as summary Gantt charts. But following best practices, summary activities have no work or resource assignments of their own.
Best practices further agree that schedule managers should not link summary activities to other line items. On the surface, linking summary activities sounds convenient. In practice, adding dependencies to summary activities creates strong potential for unnecessary and unintended logic errors. The primary problem with building dependencies into summary activities is that it creates competing or mutually exclusive logic branches through a single critical path. For rough analogy, consider navigating a car trip using a combination of three separate routes to reach the destination. The branches created by summary activity dependencies often cause breaks in the flow of the critical path. The schedule file, like the needlessly complicated trip, is hard to follow, and more prone to errors and unforeseen complications.
More abstractly, summary activities are not real. Like a folder on a computer, their substance is defined by what is housed within them. A summary activity’s duration, effort, start and finish dates are definable by their subtasks. Setting dependencies or date constraints on a summary activity attempts to link a real event such as drafting a document, to a construct such as a lifecycle phase.
Figure 4 shows an example of how summary activity logic complicates traceability. Consider the task Build New Data Model (10) in Figure 4. The schedule logic shows that this task cannot start until the Requirements Analysis and Design (3) activity is complete. Since Write Design Documents (6) has no successor we can postpone this task without impacting the start of Build New Data Model (10). Unfortunately, this is not true. The summary activity dependency obfuscates the critical path. In a large project schedule, predecessor/successor relationships between tasks and summary activities can cause perfectly normal date changes in one part of the schedule to shift seemingly unconnected line items erratically.
The time it takes concrete to dry and the time a customer requests to review a document are outside the project’s control. Such gaps in activity are commonly and correctly represented by lag. Lag is also used as a crutch to stagger tasks expected to run 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 an unstated assumption into the schedule file. 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 is able to make consistent, highly predictable progress during the entire effort. This assumption may be reasonable for an experienced writer performing a well understood task. But why is the handoff based on a measure time instead of number of specifications written? If the writer’s progress is delayed, their prediction of the handoff date is unlikely to make sense compared to the lag time.
Setting up the computer lab has a lag based on progress made. Progress lag can be conceptually less abstract than duration lag. For example, a 60% completion lag between writing and reviewing technical specifications may suggest the reviewer will begin their review when the first three specifications are drafted. However, percent complete is an often arbitrary and unsubstantiated progress measure. Despite the PCs being on backorder, the computer lab installers may safely claim 60% progress for setting up the desks, chairs, monitors, keyboards and mice. The schedule logic provides no explanation for why connecting power and networking is inhibited from starting.
The examples depicted in Figure 5, are straight forward to investigate and resolve. However simple logic resolutions are not common on most projects. Dependency lag can cloud what needs to happen, when it is used to build schedule logic on undeclared assumptions.
Like Finish-Finish and Start-Start dependencies, Constraint dates can be used 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 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 Casesand 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 15th? 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 are dangerous. They are capable of divorcing the schedule logic from reality. In Figure 6, the project completion date is given a hard deadline of April 7th. However, in Figure 7 the delay to testing creates an impossible scenario. The project must finish on April 7th. But testing won’t complete until April 11th. Which absolute wins out? Will the conflict even be noticed before it becomes a crisis?
A cursory glance at the project’s major milestones shows no issue, because the project is still scheduled to complete on April 7th. The hard constraint inhibits the schedule manager’s ability to identify the risks to the schedule.
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. Despite honest intentions, this 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.
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 8will be discussed in later articles.
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. Dependency and Sequencing Techniques will cover how to correct common schedule logic mistakes once they are identified.