There are several types of task dependencies; most people use the default type which is fine in a lot of cases but sometimes another type works better. The purpose of this article is to explain how and when to use the different types.
What are dependencies?
In a project scheduling tool dependencies are the conditions that a task requires for starting or finishing. There are three situations that cause a dependency:
An external dependency is driven by an event outside the plan and is usually fixed in time. A task constraint is the best way to represent this, with an added milestone for visibility.
An indirect dependency is the result of resource constraints. When the same resource is required by two tasks, and that is the only interdependency between them, then one task needs to take precedence over the other. The best way to control this situation is by allocating relative priorities to the tasks so one will be scheduled ahead of the other. By default the software uses an internal algorithm to optimise the plan when resource levelling is used.
An internal dependency is created by the relationships between the work characteristics within the task. There are four types of relationships:
This is the default and most common situation. The work on the predecessor task must be completed before work on the successor can start. An example of this is writing test cases before conducting the test, or writing specifications before coding.
In this case a task can only start when its predecessor has started. An example is development of a prototype using Joint applications development sessions (JAD). Work on the prototype is concurrent with the JAD sessions but should not precede them.
The successor task cannot finish after the predecessor (although it can finish before). An example of this situation is the review of documentation. The review can commence with a draft of the document but cannot finish until the document itself is complete.
The date of the predecessor follows the date of the successor. An example is the preparation of the release documentation before implementation. In this case a SF link from the implementation task to the documentation task ensures that the work is complete just before implementation, and that if the date of one task changes, the date of the other task changes with it.
This useful but obscure feature will be fully discussed in the next article.
The lag time controls the amount of time to lapse between dependent tasks. It can be a positive number to model delays or a negative number to model overlaps.
Note that there is a difference in the way the Start-to-Finish dependency is treated by Project and OmniPlan at the beginning of the Schedule. Project pushes the dependent task to the left of the project start date, and OmniPlan respects the defined date.
The correct dependencies should always be used instead of fixing task dates with constraints to ensure that when a date slips the impact on the whole project can easily be determined and managed.