Perhaps every project practitioner is aware of 4 basic types of project dependencies and two types of activity delays. Unfortunately, their knowledge is often limited by these two facts. If they don’t know how to apply these correctly, it will impact the quality of project delivery model (aka schedule), which could drive wrong business decisions. I am going to publish a series of posts to explain the correct application of dependencies and delays.
Dependency Types
• Finish-to-Start (FS)
• Start-to-Start (SS)
• Finish-to-Finish (FF)
• Start-to-Finish (SF)
Types of delays
• Positive (Lag)
• Negative (Lead)
Let’s start with the most difficult type of dependency. Start-to-Finish relationship is so hard to understand that some companies even recommend avoiding it. However, dependency does not disappear only because it is not in a schedule. This is a real life scenario but the schedule is just not going to reflect it and will not be reliable any more.
Start-to-Finish dependency
Start-to-Finish is a logical relationship in which a successor activity cannot finish until a predecessor activity has started.
Stop!!! Read this again. And again. Have you already racked your brain by trying to understand how it’s even possible? Don’t worry. You will have a clear understanding of this by the end of the post.
Let’s start from a simple example:
Have you ever watched an Olympic game relay-race? My favourite race is 4 by 100 meters.
Have you noticed that a next runner could start running before the previous runner finished the run? Even more: it’s critical that both runners run in parallel until the next runner runs in full speed and holds a relay pole. Sometimes the previous runner needs to run longer than expected.
In projects some activities also must overlap.
In other words, we apply Start-to-Finish (SF) dependency when we can only finish Task A once work on Task B has started.
Unfortunately, many project practitioners use Finish-to-Start (FS) dependency with negative delay (lead) instead of using SF dependency. This approach often causes wrong business decisions and project delays. Let’s review how it may happen:
Example
The project has two overlapping activities: Task A could not be finished until Task B is started (1 day overlap). There are two ways to model such a scenario:
a) One PM uses (SF + 1 day) dependency between Task B and Task A.
b) Another PM decided to use (FS- 1 day) dependency between Task A and Task B instead.
Both schedules look similar: all activities have the same start and end dates and both projects could be completed in 10 days. So, what is the issue, then?
Let’s continue…
Task B has additional FS dependency from Task C. The second schedule (with FS logic) shows that Task B and Task C has three days of contingency (total float/total slack) and the second PM has agreed to delay these activities by three days:
The project could still be completed in 10 days.
However, have you noticed that both Task A and Task B don’t have required 1-day overlap anymore? The project plan doesn’t represent reality (!!!). It is very, very hard to notice such issues in the real schedule with many activities and complex logic.
If Task C starts with three days of delay, the whole project will take 13 days!!! This is correctly represented in the first project schedule:
I hope this example not just demonstrates the application of SF dependency but also shows how critical it is to have a schedule which could model realistic project requirements by applying correct activity and logic.
There are also other examples when SF type of dependencies could be applied in a project but a “handover” is the most common application.
Important to remember:
Use SF as Predecessor not successor for handover activities!
In our example Task A is dependent on start of Task B. So, the (SF + 1 day) is PREDISSESOR dependency (not a successor) for the Task A and SUCCESSOR dependency for Task B. There are three conclusions from this rule:
Conclusion N1:
It is theoretically possible that Task A will not have any successor.
It happens when the handover is completed and the predecessor stream doesn’t drive any other activities in the project. It is still good practice to link the activity to completion milestone.
Conclusion N2:
It is theoretically possible that Task B will not have any predecessor.
It happens if the activity is driven by event or availability of resource. It is still good practice to link the activity to commencement milestone.
Conclusion N3:
Task B has to have a successor dependency to another activity apart from Task A.
Otherwise Task B is not required for project.
Could you think about a case in your project when your Start-to-Finish relationship is appropriate?
Alex Lyaschenko
PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma
