The launch date looks achievable until someone asks when the supplier will provide access. A project dependency is work or an input that another activity needs before it can proceed. Manage dependencies by naming the required result, owner, needed-by date and consequence of delay.
Photo by Kaleidico on Unsplash.
Map outcomes rather than vague relationships
“IT supports training” is too broad. “Training uses the approved test environment with the agreed user permissions” identifies an input that can be checked. Confirm the dependency with both the provider and the person waiting for it.
Keep a short dependency table
Predecessor result or external input.
Activity that depends on it.
Provider and receiving owner.
Confirmed delivery date and required-by date.
Evidence of acceptance.
Effect if late and escalation trigger.
Use a shared note or spreadsheet if that is sufficient. Link the table to the working plan so a changed input date leads to a revised forecast rather than two conflicting records.
An illustrative launch sequence
A service team needs supplier access before configuration, configuration before representative testing, and accepted testing before user training. If access arrives late, ask which later activities can genuinely move in parallel and which cannot. Do not recover the schedule on paper by removing an essential predecessor.
Review the dependencies that control the next milestone
At each check-in, inspect unconfirmed inputs, approaching required-by dates and changed assumptions. Escalate while a useful choice remains available. A supplier response date without commitment should remain an assumption, with an owner to confirm it.
Related guidance: small-team project planning guide.
When several projects depend on the same specialist, review their combined demand. Separate plans can each look feasible while competing for the same person. Hili Consulting can help make these relationships visible and rebuild a credible delivery sequence.
