How to Manage Project Dependencies: A Practical Guide

Project dependencies are the links between tasks, decisions, teams, suppliers and other projects that determine when work can start, continue or finish. Understanding the different dependency types in project management – and actively managing them – helps PMOs and project managers build realistic schedules, reduce delivery risk and keep stakeholders informed before problems reach the critical path.

Managed well, dependencies turn a project plan from a static list of dates into a live model of how delivery actually works. Managed poorly, they become hidden blockers that create delays, rework, resource clashes and stakeholder frustration – which is exactly why dependencies in project management deserve more attention than a single line on a Gantt chart.

What are dependencies in project management?

A dependency is not simply a statement that one task happens before another – it shows which activity controls the timing of another activity. The predecessor is the task, milestone, decision or deliverable that drives the timing; the successor is the task that is affected. The predecessor may finish before the successor starts, start at the same time, finish at the same time, or even start after the successor has already begun.

Most project schedules change as soon as delivery begins. Priorities shift, assumptions prove incomplete, decisions take longer than expected, and external inputs arrive late. Good project management dependencies practice helps project managers, PMOs and delivery teams understand what is connected to what, who owns each link, what could be delayed, and where intervention is needed before the impact spreads.

A modern approach to project dependencies should make four things clear:

• Relationship – how the two pieces of work are connected.
• Reason – why the dependency exists in the first place.
• Owner – who is accountable for managing it.
• Need-by date – when action or input is required.

From our own PMO research

In our State of Project Management research, dependency management is one of the areas where PMOs report the greatest growth in responsibility over the last five years – alongside assurance and technology enablement. As PMOs mature, the ability to see dependencies coming, not just react to them, is increasingly what separates a reactive team from a strategic one.

Dependency types in project management

Scheduling tools such as Microsoft Project commonly use four logical dependency types: finish-to-start, start-to-start, finish-to-finish and start-to-finish. Finish-to-start is the most frequently used, but the others are valuable whenever activities overlap or need to align at key points.

The Four Core Dependency Types

The four core dependency types used in project scheduling.

How to choose the right dependency

Don’t start by asking “which task comes first?” Start by asking “which activity controls the timing of the other?” The right dependency should reflect the real delivery relationship, not simply the order in which tasks appear in the plan.

1. Identify what the task needs before it can start or finish.
2. Decide whether the predecessor’s start or finish is the controlling event.
3. Decide whether the successor’s start or finish is being controlled.
4. Add lead time or lag time only where it reflects real working practice.
5. Record the dependency owner, need-by date, status and escalation route.

Examples of project dependencies

Dependency types describe the logical rule; dependency examples describe where those rules show up in day-to-day delivery. In practice, most project dependencies fall into a handful of recognisable categories:

• Task dependencies – one activity in the plan controls the timing of another, e.g. testing can’t start until configuration is complete.
• Resource dependencies – work is delayed because a person, team or piece of equipment isn’t available.
• Technical dependencies – one deliverable relies on a specific system, platform or piece of infrastructure being in place.
• Decision or governance dependencies – work can’t proceed until a sponsor, board or steering group makes a call.
• External or supplier dependencies – delivery relies on a third party, vendor or another business area.
• Cross-project dependencies – one project’s output is needed by another project, often run by a different team.

Watch out for single points of dependency

In our PMO Dark Arts webinar, we describe this as the “Bob problem” – the person who has been in the business so long that everyone relies on them. When “Bob” is unavailable, dependent work stalls because critical knowledge sits with one person rather than the team. It’s a resource dependency that rarely appears on the schedule until it becomes a crisis.

Cross-project dependencies vs task dependencies

It’s easy to assume dependencies only exist within a single project plan, but cross-project dependencies are a distinct – and often higher-risk – category. A task dependency sits inside one schedule and is owned by one project manager. A cross-project dependency crosses schedules, teams and sometimes portfolios, which means it needs visibility above any single plan to be managed well.

Task dependencies sit inside one project; cross-project dependencies sit between them.

Cross-project dependencies are often described in terms of what one project gives another, and what it gets in return. If Project A is due to deliver a data migration that Project B’s go-live depends on, that’s a ‘give’ for Project A and a ‘get’ for Project B – and it needs its own owner, need-by date and RAG status, tracked at PMO or portfolio level rather than buried in a single project plan.

This is a big enough topic to deserve its own deep dive – we’ll be publishing a dedicated guide to managing cross-project dependencies soon, covering how PMOs can track gives and gets across a whole portfolio. (Link to be added once live.)

How to build a project dependency log

Use a dependency log to make important links visible, owned and actively managed. Review it regularly as part of project governance, delivery stand-ups or PMO reporting, so that emerging risks are escalated before they affect the critical path.

Frequently Asked Questions