Project scheduling – Using Start to Finish dependencies

Introduction

The most popular type of dependency between tasks is Finish-to-Start because its purpose is very clear and this situation is met all the time. Start-to-Start and Finish-to-Finish dependencies occur sometimes in cases when the start of finish of related tasks requires synchronisation.

The last type of dependency is Start-to-Finish, which is the opposite of the normal case and its use is not obvious. We will check a special scheduling situation where this type of dependency is very useful, and we will discuss how to implement it correctly.

Just in time tasks

Just in time (JIT) tasks should be completed at the latest possible moment to minimise re-work and free up resources to carry on with other preparation tasks. Typical JIT tasks are preparation of release notes, development of training material, delivery of training sessions, performing user acceptance testing, development of interfaces, etc. In all these cases the work must be completed just before the successor task, and the task dates should follow changes in the dates of the dependent task.

There are several possible ways to schedule this situation:

  • Use a milestone to start the task allowing just enough time for its completion
  • Use the ‘as late as possible’ constraint
  • Use Start-to-Finish dependencies

A milestone is a simple way to solve the problem but requires manual calculation and maintenance in case of project changes. This is bad scheduling practice because fixing dates on a schedule limits flexibility to do dynamic scheduling and may result in an faulty schedule.

Using a constraint also solves the situation but creates other problems. There are two types of constraints, a fixed date, or the directive As Late as Possible. A fixed date should be avoided for the reasons explained before. The directive reverses the time sequence of the schedule, consuming all the available slack. This is fine if the only slack is that of the tasks under consideration, but usually the successor tasks also have slack which should be preserved. Essentially the first task with a directive of ‘as late as possible’ creates a critical path for all its dependents, and this may not be the intended result.  It is not possible to model the situation where task B finishes as soon as possible and is preceded by task A which finishes as late as possible.

The correct way to model JIT tasks is to use Start-to-Finish dependencies. In this way it is possible to create a series of tasks that will be executed immediately before the nominated milestone or successor task and will ‘float’ with it. The whole sequence will be completed as soon as possible and will stay together as a single unit.

How to create the JIT dependency chain


O-Floating-Tasks

The links have to be created in reverse order; creating Start-to-Finish links from the successor task to the predecessor task. Where there are multiple tasks concerned the process begins with the last successor and works all the way backwards through the chain to the first predecessor. In practice a normal link is created ‘backwards’, then changed from FS (the default) to SF. If lag is required, it must have opposite sign.

P-Floating-Tasks

The earlier method creates dependent tasks. Sometimes the tasks should be concurrent. THat is easily done by using Finis-to-Finish dependencies.

Conclusion

JIT scheduling is very useful in real situations. A schedule that correctly models that scenario is easy to create, easy to support and gives the project manager early warning of the impact of changes in other parts of the schedule.