Relationship Types

The DCMA states that at least 90% of all activity relationships should use the Finish-to -Start relationship

There are four types of logical relationship used in programming, these are as follows:

Finish–to-Start

Where the preceding activity must finish for the following activity to start.  

The Finish-to-start relationship provides the most explicit representation of the logical network of activities in a programme.  Ideally, all tasks in the schedule would be sequenced this way to have the clearest understanding of the critical path.

However, there are times when it’s appropriate to use alternative relationships, and so…

The other types of relationship are as follows:

Start–to–Start

Where the following activity starts at the same time as the preceding activity

Finish–to–Finish

Where the following activity cannot finish until the preceding activity finishes

Start-to-start or finish-to-finish relationships may be used in cases where they reflect the true nature of the dependency.

For example, it’s reasonable that compliance monitoring would not start until the activity being monitored begins.

It also stands to reason that an inspection process can’t finish until the process or product being inspected is complete.

However, Start-to-Start and Finish-to-Finish relationships should not be used simply to programme activities in parallel if they do not truly depend on each other. In such cases, it’s better to give the two parallel activities the same finish-to-start predecessor(s).

Start–to–Finish

Where the successor activity cannot finish until the predecessor activity starts

Start-to-Finish relationships can be very confusing when programming the logic and can seriously impede the calculation of critical path with only the slightest mistake in placement. 

Given their potential to cause error, unexpected results, confusion and lack of clarity, they should be used only with extreme care, and preferably not at all.  Because of their high level of risk, I’m going to talk at length about them.

First common mistake to note is that if you are programming backwards from an end date you do not use Start-to-Finish relationships. You still use Finish-to-Start but with a Late-as-Possible constraint rather than Early-as-Possible.

Even if you can think of a valid case for using Start-to-Finish relationship, there is very often a clearer, more transparent method of programming the logic in a way that is far less confusing or risky.

You may know exactly what you are trying to achieve when using them.  But consider the perspective of other people looking at the programme in 6 months-time.  Are they going to easily ascertain your reasoning?

One of the best examples I’ve seen for an apparent argument for the use a Start–to–Finish relationship is in the following scenario

A greenfield site needs a new high voltage power line to be constructed in order to bring power to the site.  Consequently, all power must be supplied by generators until the power line is made live, hence the generators cannot finish until the power supply starts.  

Let’s look at how the logic flows through the process…

The generator is actually a level of use activity rather than a section of work to be completed.  By this I mean that the activity is shown in the programme, however the reason for it being there in this instance, is to track the time and cost on hire for the generators.  It has no effect on programme or critical path (unless it were to breakdown – but that’s an issue for another day), however, there are some fishhooks in trying to use it. Here is the jigsaw of tasks we need to look at.  At this point we have the main relationships between all the activities programmed, all relationships are Finish-to-Start except for the generators which have a Start-to-Finish predecessor relationship.  I’ve also turned on the critical path and slack indicators in order to clarify the logic within these relationships.

As you can see above, Project calculates that there is an amount of slack in the generators which carries out past the end of Task 6.  This is because there is no Successor Task linked to the Generators.  The Start-to-Finish relationship with the Mains Power is a predecessor to generator not a successor.  The positioning of the link line can lead to confusion about what’s happening. 

Now let’s look at what happens if the Power line takes longer to construct than planned.

As the construction time lengthens, the generators activity is dragged out by the relationship with mains power.  This creates a Lag at the start, where the generators should be running but aren’t. 

To correct this the duration for the generators would have to be altered manually in order reconcile with the extended construction works. 

Now let’s consider using the DCMA recommendation that whenever possible a Finish-to-Start relationship should be used.  Accordingly, we replace the Start-to-Finish with a Finish-to-Start dependency in which the Generators now become the Predecessor to the Mains Power.  

In this scenario the logic diagram looks identical apart from missing an arrowhead at the end of Task 5 (the generators), which now shows as a critical activity.  However, there’s no confusion about how the relationships and dependencies flow through the process, so it is cleaner and more transparent in its logic.

Now let’s look at what happens if once again the Power line takes longer to construct than planned.

This time Task 5 (the generators) stays in place and a period of slack opens between it and Task 4.  Consequently, once again the duration for the generators would have to be altered manually in order reconcile with the extended construction works. 

So, although the Finish-to-Start relationship is arguably a better solution than a Start-to-Finish relationship, in this case, it doesn’t necessarily mean that it’s the best.

For the sake of being thorough in the approach to this problem (and even though its going off a little off topic) I’m going to share how I would deal with this scenario.

As mentioned earlier, the generator activity is a level of use activity intended to identify a resource cost and duration. Hence, I would programme it as something called a Hammock Task.

In a Hammock Task the duration is set by creating a dynamic link to other tasks that define the start and finish dates, which in turn automatically update the duration of the activity as circumstances change.  This creates an activity which does not affect the critical path but allows calculation of cost and duration for a resource such as in our example scenario.

Here the logic runs through Tasks 2, 3, 4 & 6 as a straightforward Finish-to-Start chain of events, and Task 5 is programmed as a manual Task without duration.

To create the dynamic link, choose the task which will create the start date for the hammock Task (the start milestone), and right click on the start date cell and choose copy cell.

Then right click the start date of the Hammock Task and choose Paste Special in the pop-up. 

This will bring up the Paste Special dialogue box, choose the Paste Link radio button and OK.  This has now linked the start date to the start project date.

Repeat the process for the end date by copying and linking the end date in Task 3 (Switch-over).  The Task duration will now be created based on the dates of these two events.

This time, when the construction of the powerline duration extends, Task 5 automatically recalculates to suit.  Be aware that it may take a minute or so to update especially in a large programme.