Project dependencies
Identify what must be available before another piece of work can succeed.
The idea
Dependencies connect tasks, resources, decisions, or external deliveries. They may be technical, organizational, contractual, or capacity-related. Record the owner, expected availability, and impact if a dependency slips. Do not assume every task can run in parallel. Dependency review also helps identify shared failures, such as recovery plans that depend on the same unavailable identity service.
In practice
A logging rollout needs access approval, storage capacity, source configuration, and a receiving investigation workflow. Missing any one can delay usable coverage.
A common misunderstanding
An external team’s informal promise is not a verified delivery dependency.
Check your understanding
How should a risky dependency be managed?
Think it through: Assign ownership, confirm dates and assumptions, monitor it, and plan a fallback where practical.
Make the relationship explicit
A dependency states that one activity needs something from another activity, team, supplier, or external decision. It should identify the required input and when it is needed. Saying that a security project depends on IT is too vague to manage. Saying that the pilot needs a test identity tenant and approved administrator access by a specific planning point gives people something concrete to coordinate.
Dependencies can be technical, organizational, contractual, or informational. A restore test needs usable backup data, but it may also need application owners to validate the result. Some dependencies are hard constraints; others reflect a preferred sequence that could change. Challenge the relationship respectfully before accepting that every activity must wait.
A fictional endpoint deployment
An academy plans to deploy an endpoint agent to staff laptops. The deployment team needs a device inventory, compatibility testing, and a distribution mechanism. The support team needs a removal procedure for failures. Procurement must clarify license coverage. Treating these as separate promises without named owners allows a missing input to surface only on deployment day.
The delivery lead records what each party will provide, who confirms it, and the effect of a delay. A weekly conversation focuses on uncertain inputs rather than simply asking whether everybody is on track. If compatibility testing finds an unsupported device group, the plan can split that group into a later decision instead of blocking unrelated preparation.
Describe a useful handoff
Pick two tasks in a fictional security awareness project. Write the output of the first in terms the second task can use: approved wording, a participant list, or an accessible training page. Add an owner and a confirmation method. Then imagine the input arrives incomplete. Explain whether the receiving task can proceed safely, needs rework, or requires escalation. This makes the dependency observable rather than assumed.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
UK Government: Project Delivery Functional Standard