---
{
  "title": "Project dependencies",
  "summary": "Identify what must be available before another piece of work can succeed.",
  "topic": "delivery",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    3
  ],
  "aliases": [],
  "sources": [
    {
      "title": "UK Government: Project Delivery Functional Standard",
      "url": "https://www.gov.uk/government/publications/project-delivery-functional-standard"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## 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

- [[project-scheduling]]
- [[critical-path]]
- [[project-risk]]