Create a dependency when one task genuinely cannot start or finish without the other. If the order is only convenient or habitual, you don’t need one. A recorded dependency is not just information. It is also a warning, and every unnecessary warning weakens the real ones.
If the concept itself is still unclear, start with what a task dependency is.
What makes a dependency real
A link between two tasks is a real dependency if at least one of these is true.
- It needs a tangible result. The second task needs the output of the first, such as an approved plan, a piece of data or a delivered component.
- Someone else does the work. When two people’s work is connected, the order no longer lives in one person’s head. If it isn’t recorded, nobody else can see it.
- A delay carries over. If the first task slipping puts the second task’s deadline at risk, the link needs to be visible.
- There is no way around it. No temporary workaround would let the second task move forward.
There is also a simple test. If the first task slipped by two weeks tomorrow, would the second one have to stop? If yes, it is a dependency. If not, it is just a sequence.
When not to create a dependency
Knowing when you don’t need one is just as important. Too many recorded links hurt visibility as much as too few.
When the order is just habit. We do many things in a familiar order even though they could be swapped. In that case a dependency builds an artificial constraint.
When the same person does both, close together. If someone writes a draft and then finalizes it themselves, they don’t need to record the order in a system. It is different if weeks pass between the two steps or if others are waiting for the result.
When the tasks are tiny. Linking two ten minute to-dos is not worth it. You are probably looking at one task with a few steps.
When you need information, not a result. If asking someone a question is enough, it isn’t a dependency. A comment or a quick conversation solves it.
The problem with too many dependencies
If every task is linked to every other, the network becomes unreadable. The dependency graph turns into a tangled web that no longer shows what actually matters.
The other consequence is human. If a large share of tasks show up as blocked, the team learns to ignore that signal. When a real obstacle appears, it gets lost in the noise.
In MyPro Sync, for example, a blocked task automatically gets a “blocked” marker until the obstacle is cleared. That is useful when the marker is rare and real. If half the tasks are blocked, the marker no longer says anything. The article on what a blocked task is goes into this in more detail.
The problem with hidden dependencies
The opposite extreme is the unspoken dependency. Everyone knows the marketing material is waiting for the product description, but it isn’t written down anywhere. As long as everything goes well, this causes no trouble.
It becomes a problem when the first task slips. The owner of the second task often only discovers right before their own deadline that they have nothing to work from. The delay then shows up in two places, and in neither of them on time. This mechanism is behind many situations where tasks slip even though everyone is working.
How to decide in practice
When you add a new task, three questions are enough.
- Does this task need something that someone else produces?
- If that is late, will this task be late too?
- Does everyone affected know this right now?
If the answer to the first two is yes and the third is no or uncertain, create the dependency. If either of the first two is no, you probably don’t need one.
Dependencies are not permanent. If the situation changes, for example you find a temporary workaround, remove the link. An outdated dependency is just as misleading as a missing one.
A dependency is only worth something when it marks a real obstacle. With fewer but accurate links, your team will notice in time when something gets stuck.