There are two common ways to classify task dependencies. The first describes how two tasks connect in time. There are four such types, and in everyday work finish-to-start is by far the most common. The second describes why the dependency exists, whether it comes from the nature of the work, a team decision or something outside the team. Both are worth knowing, because each tells you something different about a project’s risks.
Predecessor and successor tasks
Every dependency has two parties. The predecessor is the task the other one depends on. The successor is the task waiting for the predecessor. If layout can only begin once the copy is written, copywriting is the predecessor and layout is the successor.
The same relationship is also described by direction. From the successor’s point of view, the predecessor is an upstream dependency, earlier in the chain. From the predecessor’s point of view, the successor is a downstream dependency. This vocabulary helps when you need to assess the impact of a delay, because a delay always ripples downstream.
The four timing types
Project management distinguishes four relationship types, based on which point of the predecessor is tied to which point of the successor.
Finish-to-start
The successor can only start once the predecessor has finished. This is the most common type and the easiest to understand. A wall can only be painted after it has been plastered. A contract can only be signed after legal approval. When a team lead talks about a dependency, this is almost always what they mean.
Start-to-start
The successor can start once the predecessor has started. You do not have to wait for the end, but you cannot begin earlier. For example, translation can start as soon as writing is under way and the first chapters are ready. The two tasks run in parallel with a small offset.
Finish-to-finish
The successor cannot finish until the predecessor has finished. For example, testing cannot close while development is still going on, because the last change also has to be checked. The two tasks can progress together, but their ends are linked.
Start-to-finish
The successor cannot finish until the predecessor has started. This type is rare. The classic example is a shift handover, where the night shift can only end once the day shift has begun. In most teams’ daily work it hardly ever comes up.
Any of these types can also include a time offset. If concrete needs two days to cure before anything can be built on it, that is a finish-to-start dependency with a two-day wait. This is called lag.
What causes a dependency?
The same finish-to-start link means something very different if it reflects a hard constraint rather than a habit. That is why it pays to name the cause as well.
- Mandatory dependency. It comes from the nature of the work and cannot be avoided. You cannot put a roof on without walls.
- Discretionary dependency. It is the team’s choice, because working this way is more efficient or safer. For example, design work starts only after the full copy is approved, even though it could in principle begin earlier.
- External dependency. It depends on someone outside the team, such as a supplier, an authority or a client decision.
This classification really pays off when a project slips. Mandatory dependencies cannot be touched. Discretionary ones can be reconsidered, and if a task is urgent, you can check whether it really has to wait for its predecessor. External dependencies deserve separate attention, because they are the ones the team has the least influence over.
Sequential and parallel tasks
If there is no dependency between two tasks, they can be done in parallel. If there is one, they are sequential and have to be done one after the other. That sounds simple, yet it largely determines how long a project takes. Every unnecessary dependency forces two tasks into a sequence when they could run at the same time, and pushes out the finish date. Every forgotten dependency is a hidden risk, because someone starts work whose foundation is not yet in place. We cover when a dependency is worth recording at all in a separate article.
Which type should you start with?
Finish-to-start. It covers the vast majority of team dependencies, and everyone understands it straight away. The other timing types are mostly useful in tightly scheduled, complex projects, where overlaps between tasks are planned to the day on a Gantt chart.
MyPro Sync is built on the same basic logic. A task can be marked as blocking another, and the blocked task is flagged automatically until the obstacle is resolved. In the dependency graph view the whole chain is visible at once, which also shows which task is holding up several others.
A team that works consistently with this one type sees far more of its project than a team that tries to track every possible type. As a first step, go through the dependencies in one of your active projects and mark each one as mandatory, discretionary or external. The discretionary ones are often where the time to shorten the project is hiding.