Topic 6.1: Dependencies
We do so by analysing the relationships between tasks, which are known as dependencies.
Theoretically, there are four types of dependent relationships, but in practice you will really only ever work with two.
A finish-to-start (FS) relationship is where the predecessor task (the one that goes first) must finish before the successor task can start.
In other words, Task B cannot start until Task A is finished.
An example might be that before you build the roof of a house (Task A), you need to erect the walls (Task B).
Start-to-start (SS) is where beginning the successor activity depends upon beginning the predecessor activity.
In other words, Task D cannot start until Task C starts.
For example, you cannot proofread your business case (Task D) until writing has begun (Task C); however, you do not need to wait until the entire report is written before beginning proofreading – you might only need the first few sections to be complete.
This relationship could also be expressed as Finish-to-Finish (FF), in that Task D (proofreading the report) cannot finish until Task C (writing the report) also finishes; however, we rarely express it this way in our schedule.
This is because, as you will see when we start scheduling tasks, we are more interested in the earliest that successor (or dependent) activities can start.
For that same reason, Start-to-Finish (SF) relationships are rarely considered.
In this instance, we are expressing the finish-to-start relationship inversely by saying that Task B (building the roof) cannot finish until Task A (erecting the walls) has started.
Logically this is true, but for scheduling purposes the finish-to-start (FS) relationship is more important.
For scheduling purposes, and assuming we have the resources to do so, these tasks can be performed consecutively (in other words, one after the other), or concurrently (that is, at the same time).
Dependent activities, however, must not only start consecutively, but be performed in the correct order.
When you think about it, calculating dependencies is a task with dependencies of its own!
This is because you cannot begin to calculate the dependencies until you have at least started your WBS; and you should not finalise your estimates of the time and cost of each activity until you have finished determining dependencies.
Well, when an activity occurs may affect resource availability, the quality of its performance and a range of other factors.
Project planning is in fact an iterative activity, meaning that we are constantly reviewing and revising our assumptions as more information comes to hand.
Just because the lessons in this Module are presented one after the other, does not mean that the activities they refer to are wholly discrete in a finish-to-start sort of way!
The terms lead and lag are not linked to a dependency type; instead, they describe the pause placed between two dependent tasks beginning.
In the graphic below, Task A leads Task B by three days.
It could also be said that Task B lags Task A by three days.
As you can see, the shorthand for the dependency would be FS+3.
Similarly, Task C leads Task D by five days.
It could also be said that Task D lags Task C by five days.
The shorthand for this dependency would be SS+5.
For example, two project tasks might be ‘bake the cake’ and ‘ice the cake’.
After the cake comes out of the oven, though, you need to let it cool before you can apply the icing.
We might therefore need to insert a 30-minute lag into our finish-to-start dependency (FS+30).
Another example might be if we schedule painting a house to start 10 days after building commences, we say that building leads painting by 10 days.
The schedule shorthand for this would be SS+10.
Later on in this module when we look at ways to optimise our schedule, we might be able to reduce this lead to SS+7 or SS+5, depending on the circumstances.
Be aware for now, though, that this might introduce a level of risk into our project.
Leads and lags represent an opportunity to reallocate resources to other activities in order to achieve efficiencies.
Good project managers recognise this, and don’t let potential time and effort go to waste.