Start-to-Finish and Hammock

In a network analysis method, Start-to-Finish (SF) dependency type creates a lot of confusion and is often misused. SF logic makes a lot of sense when it is used in combination with a hammock activity.

SF dependency means a predecessor activity (A) can’t finish until a successor activity (B) starts. For example, if a project needs to move from System A to System B, they can’t stop using System A until System B is functional. They may use both systems in parallel for a while.

It means the duration of activity A can’t be fixed. If the start of activity B is delayed, the duration of A will automatically be extended. Such scenarios in the network are modelled via the hammock activity type.

Start and Finish of a hammock activity depend on other activities. So, it must have at least two predecessors. One to drive start and one to drive finish. It may not have a successor.    

Let’s review two scenarios:

1. Activity A can finish only after Activity B starts.

If Activity C is delayed, it will push the start of Activity B. If Activity A has a fix duration, it pushes the remaining part forward and creates an artificial gap. The resource demand and costs associated with Activity B will not be simulated correctly. 

Instead, the duration of activity A must be extended depending on other activities. If Activity C takes a longer duration of Activity A needs to be automatically increased. Also, if Activity C takes less time, Activity A must start earlier, and the duration will be automatically increased. 

Changing the activity type to Hammock fixes the problem. 

2. Activity B must start before Activity A can finish.

This scenario looks similar to the first scenario. However, in this case,  Activity B depends on the progress of Activity A. Similar to the first scenario, both activities have an overlap, but this scenario is not modelled by SF dependency and Hammock. 

In this case duration of Activity B needs to be automatically adjusted back (not forward) to accommodate an earlier finish to of Activity A. If the finish of Activity B doesn’t depend on another task, it will be a normal activity. If the finish depends on another task, it should have a hammock type. A hammock activity must have at least one FS or SS predecessor, so it can’t have SF predessesor with Activity A.

The FS dependency on Hammock guarantees that the start of Activity B and the finish of Activity A have an overlap.

It is worth mentioning that to have a real overlap, of may be necessary to add a small lag or lead between activities in both scenarios.

It is essential to understand which activity is a driver and which is driven. It may not be evident with the simulation of overap activities. 

Modelling an overlap scenario may require using Start-to-Finish dependency with a Hammock activity.