Start-to-Finish Dependency

Start-to-Finish Dependency

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:

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

Project Dependencies Types

Project Dependencies Types

Some companies define project interdependencies as “Hard” or “Soft” based on a type of constraint in their scheduling tool. In other situations, project interdependencies indicate a level of risk as probability, impact, or risk exposure. Some project management practitioners define Hard vs Soft based on a level of contingency in a provider or receiver schedules. This inconsistency in project interdependency definitions sometimes creates real confusion amongst project managers.

It is quite common to have a different management approach to Soft and Hard dependencies as they  have different risk levels. With such definitions, it is easy to miss a point when a dependency changes it’s type from Soft to Hard.  And since a Hard project interdependency often sits on a critical path, this situation turns into an issue that leads to the whole project delay and sometimes even generates “a domino effect” across the entire Program or Portfolio.

A dependency type is supposed to be a stable characteristic, which supports Project managers in their agreement on whether their projects are dependant or not.

SDPD Interdependency Management Framework defines three types of dependencies: Hard, Soft and  Virtual based on the nature of dependency. These types are stable, mutually exclusive and support project managers in dependency identification and risk analysis. Also, a PMO could develop appropriate solutions to manage each type of dependency.

Hard Dependencies: A -> B
Project A (Provider) is providing a deliverable to Project B (Receiver). Project B (Receiver) would not be able to deliver all its capabilities successfully if Project A (Provider) delays or does not provide a required deliverable to Project B (Receiver) within agreed time and quality.

Soft Dependency: A~>B
Project B (Receiver) dependant on Project A (Provider), but Project B (Receiver) would be able to deliver project capabilities even in a case when Project A (Provider) is delayed or cancelled.

Virtual Dependency: (A,B,C)
A virtual dependency is a dependency when different projects operate in the same environment and impacting each other. A virtual dependency doesn’t have Provider and Receiver project.

Often, but not always, Hard dependency is associated with a project risk and Soft dependency relates to opportunity. Virtual dependency could be a risk or an opportunity and is not always associated with an event or a deliverable. Often it requires visibility of project activities and is less stable.


• Project A provides a design to project B and project B is not able to progress without the design.

• Project A delivers a new PPM tool, but project B could use old PPM if the new system is not available on time.

• Two projects need the same critical resource during the same period of time
• Three projects need the same test environment during the same period of time
• Two projects deliver training to the same group of people during the same period of time
• Benefits could only be realised when two outputs delivered by different projects.

SDPD Interdependency Management Framework also includes some other critical dependency characteristics, methods and tools which support Programs and Portfolio delivery optimisation.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma