Do you understand task dependency relationships? If you’ve ever become confused when trying to decipher the predecessor from the successor in task relationships, you are not alone. Read on to discover a helpful paradigm for understanding task dependencies.
The terminology used in task dependency relationships breeds misunderstanding. The terms predecessor and successor to describe task relationships imply chronological sequencing of tasks. Because of this many project managers and schedulers think these two terms are specifying order in time.
Unfortunately, that is not the case. Well, if chronology is an erroneous perspective of task dependencies what is a proper view of task dependencies? It is better to understand the task dependencies as reflecting the cause-and-effect logical relationship between two tasks. The predecessor is the cause and the successor is the effect.
This article examines a proper non-chronological perspective on task dependencies to foster better understanding of the relationships between tasks.
Again, the terms predecessor and successor imply chronology: the predecessor comes before and the successor comes after. This terminology will only enable you to properly apply a few of the four task dependency relationships. But you will become confused, in particular, when you try to apply a Start-to-Finish relationship.
The better view or more insightful way of looking at task dependencies is the cause-and-effect relationship between the activities. These cause-and-effect relationships may come from:
- Logic: the trench must be dug before the pipe is laid in the trench. It defies rationality to say the underground pipe installation is finished before completion of the trench.
- Mandatory processes: organizational procedures require a safety briefing before commencement of the project demolition.
With this cause-and-effect relationship in mind it is helpful terminology to think of the predecessor as the independent or driving task and of the successor as the dependent or driven task. See the Figure 1 precedence diagram. In this figure Task A is the driver and predecessor and Task B is the driven or successor.
As an illustration consider the task (A) prepare for exam and task (B) take exam. The driver is the take exam task, because as the date of the exam is scheduled so the preparation to take the exam is adjusted accordingly to provide maximum prep time.
If you view these two tasks in the driver and driven sense, then you will correctly apply the Start-to-Finish dependency to define the relationship between these tasks. In other words, the start of the exam drives the finish of the exam prep. Take exam is therefore the cause (driver) and predecessor and prepare for exam is the effect (driven) and successor. Again, don’t think order in time.
If, however, your perspective was chronological, then you would observe that the exam comes after the exam preparation, and, therefore, would be the successor in a Finish-to-Start relationship. This is wrong! What if your exam prep took longer than anticipated? That would mean your exam date should be rescheduled, which is not an option for most educational exams. The exam date drives the preparation and not the other way around.
Let’s review the four task dependency types in light of our cause-and-effect and driver-and-driven perspective.
The most common relationship type is the Finish-to-Start (FS), Figure 2.
In this relationship the driver (predecessor) completes and then the driven (successor) may proceed. The most classic example is the foundation installation must complete (driver) before the walls may be erected (driven). Another helpful example is the report must be edited (driver) before it is printed (driven).
The Start-to-Start (SS) relationship is also popular. Here the driver (predecessor) commences and then the driven (successor) immediately begins, Figure 3.
This type of relationship is typically used at the beginning of the project. An example is when you begin ‘pouring concrete’ (driver), and then you proceed with ‘leveling the concrete’ (driven) right away before it cures.
The Finish-to-Finish (FF) relationship, Figure 4, is often used to closeout a phase or the entire project.
An application of the FF relationship is when you finish striking the concrete thrust block forms (driver) and then you can finish insulating the pipe (driven). This FF ensures that the pipe insulation buts up directly against the pipe thrust block. So the completion of the strike forms task (driver) enables the completion of the insulate pipe task (driven).
The least common relationship type is the Start-to-Finish (SF), Figure 5.
This is also the one that creates the most confusion if you think in terms of chronological time instead of the cause-and-effect and driver-and-driven paradigm. We’ve already discussed the test preparation and exam example. Another good illustration is ‘turning on the site power’, a cause and driver, and finish ‘running the generator’, the effect and driven.
The generator must run until the site power is activated. Therefore ‘activate site power’ is the driver (predecessor) and finish ‘running generator’ is the driven (successor). In this case the generator is already occurring or running and is, therefore, first in time before the site power is activated. However, activation of the site power is the cause (predecessor) and the effect is the finish of ‘running the generator’ task (successor).
Because this SF relationship is the most confusing type we have one more example demonstration. When the new and improved website comes online (the cause), the old website will cease (the effect). Here the old website is maintained in an acceptable and temporary state until the new website is brought online.
Again, the old website service is first in chronological order but is the effect or driver in terms of the cause-and-effect paradigm. The new website drives the shutting down of the old website, and is, therefore, the predecessor. Ceasing maintenance and service of the old website is driven by the activation of the new website, so service old website is the successor.
Although scheduling software uses the terms predecessor and successor to describe task relationships, these terms do not adequately reflect the true relationships between tasks. Do not think in terms of chronological time. It is better to describe task relationships as cause-and-effect. These cause-and-effect relationships are a result of activity logic and/or organizational processes.
It is also helpful to think in terms of a driver task and a corresponding driven task. With this cause-and-effect and driver-and-driven paradigm you will be able to more accurately define the relationships between schedule tasks. And you will know how to apply all the relationship tools at your disposal when you begin to create your schedule.
Reference: Forecast Scheduling with Microsoft Project 2010, Eric Uyttewaal, PMP