A task list can be full of activity while a project remains blocked. The missing distinction is often between work that is simply unfinished and work that cannot proceed until a specific input arrives. That second relationship is a dependency.
Consider a team preparing a customer guide. Drafting the introduction may be independent work. Finalising the screenshots may depend on an approved interface. Booking the translation may depend on knowing the final word count. Calling all three items “to do” hides the sequence.
Name the handoff, not just the person
“Waiting for design” is too broad to manage. “Need the approved mobile checkout screens from design before capturing screenshots” describes the input and its purpose. Add an owner, an expected date and the condition that makes the input usable.
A file arriving is not always the same as a dependency being resolved. It may be incomplete, unapproved or in the wrong format. Agree the acceptance condition before the handoff: which version, which scope and which approval are needed?
- Input: What exactly must arrive?
- Owner: Who can provide or confirm it?
- Need-by date: When does downstream work require it?
- Fallback: What can proceed if it is delayed?
Discuss the effect of delay
If the input slips, identify the work that changes rather than merely moving every date. Perhaps drafting can continue with placeholders while publication waits. Perhaps an early review of a partial design can expose problems without pretending it is final.
Keep dependency notes close to the work they affect and review them when scope changes. A former blocker can disappear if a feature is removed, while a small new requirement can create another handoff.
The result is a plan that explains why tasks are ordered, making it easier for people to help each other move the project forward.