How Task Dependencies Change Priority
Priority answers one question: Which available task deserves attention first?
Dependency answers another: Which task must happen before another task can begin or finish?
Mixing those questions creates confusing plans. A task may be extremely important and still be impossible to start because it depends on information, approval or earlier work that does not yet exist.
A dependency is a constraint, not a preference
Suppose a report contains these steps:
- Collect source data.
- Clean the data.
- Create charts.
- Write findings.
- Review the draft.
You may prefer to write the findings first, but you cannot write them properly before the data and charts exist. That is a dependency.
By contrast, if both “reply to supplier” and “prepare presentation” can start immediately, choosing one first is a priority decision.
The distinction is useful because a priority score should not make blocked work appear actionable.
Identify tasks that are ready now
A task is ready when every required predecessor is complete or unnecessary.
In the example above, Collect source data is ready. The remaining steps are blocked.
The Task Dependency Mapper groups tasks into:
- Ready now
- Blocked
- Unlocks other work
“Ready” does not mean important. It only means the dependency information you entered does not prevent the task from starting.
When several tasks are ready, use the Priority Picker to compare them.
Look for unlocker tasks
Some tasks matter because finishing them releases several other pieces of work.
Imagine this project:
- Approve brief
- Write landing page
- Design ads
- Configure campaign
- QA launch
If both writing and design depend on Approve brief, that approval is an unlocker. Completing it may create more progress than starting an unrelated task of similar importance.
This is why the Priority Picker includes dependency as one factor. A task that unblocks other work can deserve earlier attention even when its own output is small.
Waiting on another person is still a dependency
Dependencies are not limited to tasks you control.
You may be waiting for:
- client approval;
- a supplier quote;
- access credentials;
- legal review;
- data from another team;
- a decision from a manager.
If the next step depends on someone else, separate your active work from the waiting state.
For example:
Your task: Send the final draft for approval.
External dependency: Client approval.
Next task after approval: Schedule the campaign.
That makes the project status clearer than leaving “launch campaign” on an active task list while the approval is still missing.
Dependencies affect elapsed time
A project may require only five hours of active effort and still need a week of elapsed time.
Suppose:
- Draft document: 2 hours
- Legal review: up to 3 working days
- Revision: 2 hours
- Final approval: up to 1 working day
- Publish: 1 hour
The active effort is five hours. The elapsed duration is longer because external dependencies introduce waiting time.
The Deadline Reality Check becomes more useful when you recognise this distinction. Capacity alone cannot solve a deadline if the required review window does not fit inside the remaining calendar time.
Circular dependencies indicate a planning problem
A circular dependency occurs when two or more tasks are defined as waiting on each other.
For example:
- Finalise price depends on finalising scope.
- Finalise scope depends on finalising price.
The project cannot move because the dependency structure is incomplete.
Usually, one of three things is needed:
- a provisional assumption;
- a smaller decision that can happen first;
- a person who owns the trade-off.
The Task Dependency Mapper flags simple two-task circular dependencies so they are visible instead of silently blocking the plan.
Do not turn preferred order into fake dependencies
Not every sequence is required.
You might prefer to answer email before writing, but writing does not literally depend on email. Treating preferences as dependencies makes the map rigid and less useful.
A real dependency means the later task lacks something necessary to proceed.
Useful tests include:
- Can the task start without the earlier item?
- Can it finish without the earlier item?
- Would starting now create meaningful rework?
- Is the earlier item supplying information, approval, access or an output that the later task requires?
If the answer is no, you probably have a priority preference rather than a dependency.
Combine dependency mapping with estimation
Once the sequence is clear, estimate the tasks that control the project timeline.
If a critical unlocker has a wide duration range, the entire downstream plan may need more margin.
The Estimate Range Planner can show optimistic, likely and pessimistic duration for uncertain tasks. Then the Project Pressure Calculator can compare the remaining effort with the capacity before the deadline.
The sequence becomes:
Break down the work → Map dependencies → Estimate uncertain tasks → Prioritise ready work → Check deadline capacity
That sequence solves different planning problems in the right order.
Dependency maps should change as the project changes
A dependency map is not permanent.
An approval may arrive early. A supplier may become unavailable. A task may be removed from scope. New information may allow two steps to happen in parallel.
Update the map when those facts change. The purpose is to describe the current constraints, not to preserve the first version of the project plan.
Use dependencies to reduce false urgency
Blocked work often feels urgent because its deadline is close, but repeatedly looking at it does not create progress.
When you can clearly see what blocks the task, attention can move to the unlocker instead.
That is the practical value of dependency mapping: it turns “everything is urgent” into a more precise question about what can move now and what must happen before the rest can proceed.