Task dependencies in project management (and how to find them before they hurt)

Project dependencies are a normal part of managing any complex project. One task may require another task to be completed first, a team may depend on another team's output, or a project may be waiting for a product decision, external delivery, or approval.

Dependencies by themselves are okay. What hurts is when important dependencies are off the radar or stay unmanaged until they start wreaking havoc on delivery. Project managers cannot know every dependency themselves, so successful dependency management is less about maintaining a perfect dependency map and more about creating a process that aids the right people in discovering, assessing, and managing project dependencies early.

In this guide, we'll look at the different types of project and task dependencies, how to identify task dependencies, and how project managers can facilitate managing dependencies without becoming the dependency oracle.

TL;DR

• Dependencies are inevitable, but invisible and unmanaged dependencies create project risks for delivery. They can be internal or external, mandatory or discretionary, direct or indirect, and may arise from product, technical, or cross-domain concerns.
• Project managers don't need to discover every dependency themselves. Their role is to bring the right people together, facilitate discovery, make important dependencies visible, assign ownership, and coordinate their resolution.
• Good dependency management goes beyond tracking. Once a dependency is identified, teams should assess its impact, plan how to handle it, and ask whether it can be removed, reduced, or avoided altogether.

What is a dependency in project management?

A dependency in project management appears when achieving an outcome or starting a process requires an input from another activity, process, or external factor. Dependencies themselves aren't necessarily bad — it's just that projects inevitably contain them. A problem arises when a dependency is important enough to constrain the work, but isn't visible, understood, or actively managed.

In practical terms, whenever starting, continuing, or finishing something requires something else to happen first, you have a dependency. A dependency can be anything:

• another activity's output;
• a product decision;
• technical information;
• another team's deliverable;
• a resource;
• an approval;
• a customer response;
• an external vendor's delivery;
• an environmental condition, etc.

Dependencies come with the territory. Not knowing about them, or knowing and doing nothing, is where it goes wrong. Here's why:

• they are tricky to plan for and orchestrate collaboration around;
• they can be difficult to discover;
• the consequences of discovering an unplanned dependency can be difficult to predict;
• they can propagate delays, rework, and other problems to downstream work in a later project phase.

A dependency isn't equally difficult to manage in every context. A QA engineer waiting for a developer on the same team can usually resolve the dependency with a five-minute conversation. A product decision that requires input from product, engineering, legal, operations, and an external partner can take weeks to resolve, even if the actual decision takes five minutes.

No one, including the project manager, can know all potential dependencies in a project beforehand. Product managers understand the product; developers and architects understand the technology; other teams and specialists understand their own constraints. The project manager's role is to bring these perspectives together, facilitate dependency discovery, make dependencies visible, and help the people involved manage them.

Types of dependencies in project management

Since dependency resolution takes so much time and has a serious impact on the project’s success, it’s important to it's important to classify project management dependencies to be able to identify dependencies early and manage them better. There are a few ways to tell them apart.

Internal and external dependencies

Internal dependencies are relationships between activities, teams, or resources within the project scope or organization. Dependent tasks could also be resource dependencies, which is why resource planning and dependency management go hand in hand. 

For example, a development task may depend on another team's API, or a testing activity may depend on a feature being completed by the development team. A PM usually manages these through effective communication, clear coordination mechanisms, and good working relationships.

External dependencies involve something outside the project team's direct control. These might include a customer decision, a vendor delivery, regulatory approval, or an external system becoming available. A PM manages those by establishing strong connections outside of the team, be it with a stakeholder, a vendor, a regulator, or anyone else who has an impact on the project. External dependencies may require negotiation, contingency planning, escalation, or risk mitigation.

Mandatory vs. discretionary dependencies

A mandatory dependency exists because of the nature of the work or some unavoidable constraint. For example, you cannot deploy software before it has been built, install a component before the required infrastructure exists, or publish an update before the legal team has approved it according to company policy. A PM should plan for these and do their utmost to discover as many of them as possible. You'll also see them called logical dependencies, or hard logic.

A discretionary dependency exists because the team has chosen to perform activities in a particular order. There may be a good reason for that order, but it isn't inherently required. It often comes from the team's own Definition of Done, a decision about which quality gates are required, or clean code policies. In extraordinary circumstances, these dependencies can be challenged, changed, or removed, although doing so may mean accepting additional risk. They are also called preferential dependencies, or soft logic.

Direct vs. indirect dependencies

A direct dependency exists when one activity explicitly requires an output or condition produced by another. For example, testing depends directly on a completed build or a decision on design depends entirely on the product owner’s opinion.

An indirect dependency occurs when the relationship is mediated through another activity, team, resource, or condition. For example, Team C may depend on Team A's work because Team B cannot complete its deliverable without Team A's output.

This distinction becomes particularly useful once we get into large-scale projects, where cross team dependencies can travel through several teams and become difficult to see.

Types of task dependencies in project management

In project management, there are 4 task relationship types that exist and have a direct impact on the project timeline. Whenever someone is creating a Gantt chart in project management software to determine the critical path or to build a project schedule, it is important to have these dependencies in mind.

Finish-to-start (FS)

A finish-to-start dependency means the dependent task cannot start until its predecessor has finished.

Example: Testing cannot start until development is finished.

This is the most common type of task dependency and the default relationship people usually have in mind when they think about dependencies.

Start-to-start (SS)

A start-to-start dependency means one task cannot start until another task has started.

Example: Documentation can begin once development has started, and the team has enough information to document the feature.

The tasks can then proceed in parallel.

Finish-to-finish (FF)

A finish-to-finish dependency means one task cannot finish until another task has finished.

Example: Documentation can start independently, but it can't be finalized until development is complete, because the functionality is still changing.

The tasks can start independently, but their completion is linked.

Start-to-finish (SF)

A start-to-finish dependency means one task cannot finish until another task has started.

Example: A new support team takes over a service. The old support team's responsibility cannot end until the new team has started providing support.

Start-to-finish dependencies are relatively uncommon in typical software projects.

One important clarification

These relationships describe the timing relationship between two of the project tasks involved. They don't explain why the dependency exists.

For example, a development task might have an FS relationship with testing because of a technical dependency, while another FS relationship might exist because of a product or organizational constraint.

That's why the four relationship types are useful for planning: you can’t ignore them when calculating the duration of your project, but they aren't enough for dependency management.

The PM is not the dependency oracle

One of the expectations from a project manager is to have the broadest view of the project. However, breadth of knowledge comes at the expense of depth. A project manager can’t know the product and target audience as well as the product manager, nor the architecture and intricacies of development as well as an architect or developer.

Another useful classification, particularly in software development, is based on where the knowledge needed to identify the dependency comes from:

• product dependencies;
• technical dependencies;
• cross-domain dependencies.

Product dependencies

Product dependencies arise from the product itself: its requirements, user journeys, business rules, decisions, or relationships between product areas. For example: a new pricing flow depends on the pricing model being finalized, or feature B requires a decision about how feature A should behave.

Technical dependencies

Technical dependencies arise from the way the product is built and operated. For example: a team may depend on another team's API to implement a feature. If that API changes, the dependent team may need to change its implementation, potentially affecting its timeline.

Cross-domain dependencies

Cross-domain dependencies emerge where product and technical considerations interact. They are often harder to identify because neither the product nor the technical perspective provides the complete picture.

For example:

A product team decides that customers should see the changes to the catalog on a website in real time. From a product perspective, this may look like a relatively straightforward requirement. Technically, however, it may require changes to inventory services, data synchronization, APIs, performance, and integrations with other systems.

Why do we need this distinction?

Dependencies within a single domain can often be identified by the people working in that domain. Product people understand product dependencies; developers and architects understand technical ones. Cross-domain dependencies are different: they emerge at the boundaries between areas of knowledge, so neither side necessarily sees the complete picture.

This is where the project manager can add particular value. By connecting people and perspectives across the project, the PM can help uncover dependencies that might otherwise remain invisible — and incorporate them into the project plan and risk management.

This is where the project manager's role shifts from dependency tracking to dependency discovery and facilitation.

Dependency management: from discovery to closure

One of the roles of a project manager is to organize a process around dependency management. The goal isn't for the PM to discover and resolve dependencies themselves. It is to create a process in which dependencies are surfaced early, assessed, assigned, and managed by the people who have the knowledge and authority to deal with them.

To illustrate this better, let’s break the process of managing a dependency into several stages:

1. discovery
2. assessment of severity and scale
3. assigning ownership and responsibilities
4. planning a resolution
5. execution
6. verification and closure

The first four stages are sometimes done using a single meeting, the design of which rests on the shoulders of a PM, and the result of this meeting actually draws the difference between an easy and a hard project. Let’s take a look at this process stage by stage:

Discovery

Dependency discovery is very often just brainstorming. People simply come together in a room, or do the groundwork before the meeting, and try to fill the board with dependencies that they can think of. But if you want the session to go faster and surface the dependencies that actually matter, there are a few things you can do as a PM:

1. Do your own homework first
2. Get the right people in the room
3. Ask the right questions
4. Make it visual
5. Use a few facilitation techniques
6. Question every dependency and cut the ones you don't need

Assessment of severity and scale

The easiest way to do that is to have everyone score it on the following 4 parameters:

• severity (or impact),
• scale,
• proximity in time,
• probability.

You'll end up with a prioritized list of dependencies to keep an eye on, plus a clear sense of which ones to tackle first.

Assigning ownership

This can be a simple RACI matrix or just a clear assignee against each point. The goal is to make it clear who is responsible for moving the dependency forward — not to know whom to blame when something goes wrong.

Resolution planning

Decide what needs to happen to make the dependency safe. This might mean agreeing on a delivery date, changing the sequence of work, involving another team, preparing a workaround, or removing the dependency altogether.

Execution

Carry out the agreed actions and keep the dependency visible in a task management tool while it is being resolved. The PM's role here is usually coordination and follow-up rather than doing the actual work required to resolve the dependency.

Verification and closure

Don't consider a dependency resolved simply because someone says the work is done. Verify that the required input or outcome is actually available and that the dependent work can proceed. Then close the dependency and remove any unnecessary tracking.

How to find dependencies before they find you

Ok, all of the above sounds great, but the question arises: how should people actually discover dependencies? Is there anything people can do other than rely on simply brainstorming the problem? Most of the techniques below still involve some form of brainstorming, but they add structure or a different perspective that makes the thinking more effective.

Make the invisible visible

Eyes are an extension of the brain (seriously, look it up). For this reason or not, being able to visualize dependencies makes the job of understanding vast amounts of information a lot easier. People are much better at reasoning about relationships when those relationships are visible.

Instead of keeping dependencies in people's heads, put the relevant activities, teams, systems, decisions, or constraints on a board and make the relationships explicit. Maps, boards, schemas, charts, slides, project management tools, and even stories told through images can all be useful here.
 

Change the questions

Asking “What are the dependencies?” often produces exactly what you'd expect: a brainstorming session. A better approach is to look at the same system from several different angles.

For example, 9 Whys can help uncover dependencies hidden behind an apparently simple requirement. What, So What, Now What can help a group move from observations to implications and actions. TRIZ-style thinking can deliberately turn the problem around: What would we have to do to make this system fail? What would the ideal solution look like if constraints disappeared?

These techniques don't magically uncover dependencies. They change the way people look at the problem, which can expose relationships that a straightforward brainstorming exercise misses.

Communication principles and techniques

Some dependencies are difficult to discover not because they are technically complicated, but because the people involved don't have an established way to communicate dependencies.

For example:

• agree how quickly dependency-related requests should receive a response;
• make the owner of each dependency explicit as soon as it is identified;
• establish a clear escalation path when an agreement is at risk;
• keep dependency-related communication visible rather than hiding it in private conversations;
• avoid meetings when an asynchronous decision is sufficient.

Challenge the dependency

Finding a dependency doesn't necessarily mean that we should accept it. Once a dependency has been identified, ask whether it can be removed, reduced, or avoided.

Can the work happen in parallel? Can an interface be agreed earlier? Can a team use a mock or stub? Can the sequence of activities change? Can ownership be changed?

This is an important distinction between dependency tracking and dependency management. The goal isn't to produce the most complete dependency map possible. It's to reduce the constraints that make delivery harder.

Conclusion

Dependencies are unavoidable in complex projects. The goal isn't to eliminate every dependency or create the most detailed dependency map possible. It is to make the dependencies that can affect delivery visible early enough for the people involved to assess and manage them.

This is where the project manager adds value. A PM doesn't need to know every product or technical dependency personally. Instead, they create the conditions for the right knowledge to come together, facilitate discovery, make responsibilities clear, coordinate resolution, and challenge unnecessary project constraints. Done well, dependency management becomes less about tracking arrows on a plan and more about making the project easier to deliver.