Dependency

In project management, a dependency is a relationship between two pieces of work in which one task or deliverable must be done before another can proceed. The task that must come first is the predecessor; the task that waits on it is the successor. The most common form is finish-to-start: the successor cannot begin until the predecessor finishes — you cannot paint a wall until it is built, or run a campaign until the creative is approved. Other forms exist (start-to-start, finish-to-finish, start-to-finish), but the core idea is the same: dependencies impose order on work that cannot simply all happen at once. They are the links that turn a list of tasks into a structured plan, telling you not just what must be done but in what sequence it must happen.

Dependencies matter because they shape the schedule and reveal where the real constraints lie. When tasks are independent, they can run in parallel and the project moves fast; when they are linked by dependencies, work has to queue, and a delay in a predecessor ripples forward into everything that waits on it. Mapping dependencies is therefore how a project manager understands sequence, identifies which delays will hurt, and plans realistically. They also expose risk: a single late deliverable that many other tasks depend on is a far bigger threat than a late task that nothing waits on. Understanding dependencies is what separates a schedule that reflects how the work actually has to flow from a wish-list that ignores the order reality imposes.

Dependencies are the foundation of the critical path — the longest chain of dependent tasks that determines the shortest possible duration of the whole project. Because the critical path is built from tasks linked end to end by dependencies, any delay to a task on it pushes out the project's finish date directly, while a delay to a task off the critical path may have slack to absorb it. This is the central reason dependencies matter for scheduling: they tell you which tasks are truly time-critical and which have room to move. A project manager who knows the dependency network knows where to focus attention, because the tasks on the critical path are the ones that govern the timeline.

Dependencies also drive resourcing and risk decisions. Knowing that one deliverable gates several others tells you to protect and prioritize it, because its slipping will cascade. It informs where to add buffer, where parallel work is possible, and where a bottleneck will form. Tools represent dependencies visually — arrows in a Gantt chart, links in a network diagram — precisely so teams can see the chains and the critical path at a glance. The honest point is that ignoring dependencies produces plans that look fine on paper and fail in practice, because work that was scheduled to run in parallel actually has to wait its turn. Reading the dependency network correctly is what makes a schedule honest about how long things will really take.

Managing dependencies well starts with identifying them honestly: for each task, ask what must be finished before it can start, and what waits on it once it is done. Map those links, then find the critical path — the longest dependent chain — so you know which tasks govern the timeline. Protect and prioritize the tasks that gate many others, build buffer where a slip would cascade, and look for genuine opportunities to run independent work in parallel rather than queuing it needlessly. Communicate the dependencies to the team so everyone understands why sequence matters and which handoffs are time-critical. A clear dependency map turns a project plan from a list of tasks into a realistic picture of how the work must actually flow.

The failures are common and costly. Teams miss dependencies and then discover mid-project that work they planned to parallelize actually has to wait; they ignore the critical path and over-invest in tasks with slack while critical ones slip; they fail to flag the deliverables that gate many others, so a single delay cascades unseen; and they create artificial dependencies that force work to queue when it could run in parallel. The discipline is to map dependencies accurately, identify the critical path, protect the gating tasks, and parallelize where the work genuinely allows. Done well, dependency management produces schedules that hold up because they respect the real order of the work. Done poorly, it produces optimistic plans that unravel the moment one predecessor runs late.

In project management, a dependency is a task or deliverable that must precede another, defining the order of work and forming the critical path that governs the project schedule.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where dependency is a core concern: