Dependency Management in Projects: Types and Techniques

What is dependency management in project management?

Dependency management is the practice of identifying, recording, and controlling the relationships where one piece of work constrains another. It answers a narrow but decisive question: what must be true before this task can start or finish, and who is responsible for making that true?

The definition sounds administrative. The consequences are not. When dependencies are not named, they surface as surprises — the integration that “suddenly” needs a legal review, the release that “unexpectedly” waits on another team’s migration. Nothing was sudden. The relationship existed from the start; it was simply never written down with a date and a name attached.

Dependency management has three outputs, and it is worth checking that your process produces all three:

1. A record of what depends on what, in both directions, with owners and dates.
2. A schedule where the wait appears as duration, not as an assumption.
3. A response plan for each dependency that could realistically fail — an alternative, a buffer, or a decision date.

If your team has the record but not the response plan, you have an inventory, not a control system.

Which dependency types actually matter?

The four logical relationship types describe timing. They are necessary vocabulary, but they are not the most useful lens for management decisions. The cause of the dependency determines what you can do about it.

Start with timing. Every schedule link is one of four types, and each has a different effect on the critical path.

Two modifiers sit on top of these links. A lag adds waiting time: concrete needs five days to cure before the next trade starts, so the FS link carries a five-day lag. A lead allows an overlap, effectively negative lag: you start writing the manual before the product is finished. Both are legitimate modelling tools and both are frequently used to hide optimism. A schedule full of negative lags is usually a schedule with an unstated assumption that parallel work will not conflict.

Now the classification that changes decisions:

• Mandatory (hard) dependencies are inherent — physical, legal, or contractual. You cannot test software before it is built. You cannot ship regulated content before approval. These cannot be removed, only buffered or re-sequenced.
• Discretionary (soft) dependencies are choices, usually described as “best practice.” A design review before development, a specific team doing a specific job, a fixed sequence inherited from a previous project. These are the cheapest dependencies to remove, and the least examined.
• External dependencies sit outside your authority: a vendor delivery, a regulator, a client decision, a platform release. You cannot control them, so you manage them with buffers, contractual dates, and early escalation.
• Resource dependencies exist because one person or asset is shared. Two projects needing the same database administrator is not a logic problem; it is a capacity problem.

The practical rule: mandatory and external dependencies get buffers, discretionary and resource dependencies get challenged. Most schedule compression comes from the second group, and most teams spend their energy on the first.

> Common mistake: Labelling every dependency “mandatory” because it is currently true. A dependency is mandatory if it cannot be changed, not if it has not been changed yet.

Why do dependencies turn into delays that look like surprises?

Because the delay happens in the gap between two owners, and gaps have no owner by default. A task has an assignee; the wait between two tasks has nobody, unless you create one.

There is a second reason, and it is arithmetic. Dependencies chain. If each link in a five-step chain has an 80% chance of being ready on time, the probability that all five are ready is 0.8⁵, or about 33%. Each link looks reliable. The chain does not. Add float and it gets worse: float belongs to a path, not a task, so when one task consumes three days, every task behind it loses three days of protection while still believing it has its own.

The final reason hurts most: waiting is invisible on a task board. A card in “blocked” looks like a card in progress to anyone skimming. Dependency management is largely the discipline of making blocked work visually and numerically distinct from working work.

How do you build a dependency register people actually use?

Keep it small, keep it dated, and keep it attached to the work rather than to a separate spreadsheet that only the PMO opens.

A register that survives contact with reality has these fields:

Two fields do most of the work. Age catches the dependency that is technically “in progress” and has been for six weeks; anything over ten working days should be escalated or re-planned, not re-reported. Promised date versus needed-by date turns a vague conversation into a negotiation about a specific gap.

Review the register on a fixed cadence — weekly for delivery teams, fortnightly for programmes — and review it *before* the status meeting, not during it. The register’s purpose is to produce decisions, not to produce a document.

> Practical tip: Add one line to your weekly update: “Dependency that worries me most this week, and what I did about it.” One sentence forces a name, a risk, and an action.

What techniques remove dependencies instead of just tracking them?

There are only two strategies: break the dependency, or reduce its impact. Everything else is a variation. Teams that only reduce impact end up with a well-documented, well-attended, permanently slow process.

Break the dependency:

• Agree an interface contract and work against a stub. If team B needs team A’s service, define the request and response shape, then let B build against a mock. The dependency on A’s progress disappears; only the final integration remains.
• Split vertically instead of horizontally. Delivering one thin end-to-end slice removes the cross-team handoff that a layer-by-layer plan creates.
• Question the sequence. Many reviews, sign-offs, and “gates” are discretionary. Removing one approval step often removes a week of queue time.
• Buy or borrow instead of build. A commercial component can eliminate a dependency on scarce internal capability, at the cost of licence fees and vendor risk.

Reduce impact:

• Add a feeding buffer before the dependent activity rather than padding each task. Protection stays the same; the padding does not get consumed invisibly.
• Pre-order long-lead items before the plan needs them, accepting a small carrying cost to remove a large schedule risk.
• Define a workaround in advance. “If the API is not ready by day 40, we ship with manual upload” is a plan. “We’ll deal with it” is not.
• Escalate on a date, not on a feeling. Set the escalation trigger when you log the dependency: “if no confirmed date by 14 March, escalate to the steering group.”

The strongest programmes use both strategies in order: try to break first, then buffer what remains, then escalate what is still exposed. Buffering first is how projects end up slow and still late.

How do you manage dependencies across teams you don’t control?

Give each cross-team dependency a named pair — one owner on each side — and a single agreed date. Everything else is theatre.

Cross-team dependencies fail differently: nobody has authority over both sides, each team optimises its own queue, and status degrades at every boundary. Three mechanisms work:

1. A named pair per seam. The requester owns the needed-by date and the definition of done; the provider owns the promised date and the delivery. When either changes, both are notified. A dependency with a “team” as owner will drift.
2. A shared, dated view. Both teams should see the same dependency with the same dates in the same tool. Two registers reconciled monthly is a rumour mill with extra steps.
3. A short cross-team sync with a dependency-only agenda. Fifteen minutes, only blocked items, only decisions. The Scrum-of-Scrums pattern exists for this reason: it is a dependency forum, not a general status meeting.

Also agree what “done” means at the seam. Half of cross-team delays are not late deliveries; they are deliveries that the receiving team cannot use because the format, environment, or acceptance criteria were never pinned down.

Two worked examples

Example 1: a fourteen-week platform programme. Six teams, one launch date, and 22 cross-team dependencies identified in week two. Mapping them revealed that three sat on the critical path with zero float: the identity migration, the billing cutover, and the data export.

The integration test needed four upstream teams to be ready. Its earliest possible start was the *latest* of the four finish dates, not the average — a detail that turned a comfortable plan into a two-day margin. When a legal review of the vendor data-transfer agreement surfaced in week seven, it needed ten working days after signature. Signature landed on day 52, review finished on day 66, and the ten-day integration test pushed the finish to day 76 against a launch at day 70.

The dependency was not new. It existed since the vendor was chosen, but it was not in the register, so it was not in the schedule, so it was not in any risk review. Cost of the omission: a six-day slip. Cost of preventing it: one column in a spreadsheet.

Example 2: pooling buffers instead of padding tasks. A five-task chain, each estimated at eight days, with each owner quietly holding three days of safety. Total plan: 40 days. Actual work content is roughly five days per task, or 25 days.

Pool the safety instead of hiding it: 25 days of work plus a single 12-day buffer at the end of the chain. The plan becomes 37 days, the protection is visible, and the buffer is consumed only when something actually goes wrong. If the chain finishes early, the team delivers early rather than spending the slack on polish nobody asked for. This is the core insight of critical chain scheduling, and it works because pooled buffers are managed, while hidden padding is not.

What are the trade-offs?

Every dependency control costs something, and pretending otherwise is how teams end up with process they resent.

• Decoupling costs design effort and creates integration debt. Stubs and interface contracts let teams work in parallel, but the final integration becomes a single, concentrated risk. Budget real time for it.
• Buffers consume schedule up front. A 12-day buffer looks like 12 days of waste on a Gantt chart until the first surprise absorbs it. Teams that remove buffers to look fast usually finish late.
• Registers go stale. A dependency log with 80 open items and no owner for curation is worse than a short one with 15. Prune aggressively.
• Formal dependency management suits some contexts badly. For a two-person team shipping weekly, a register is overhead. For a 60-person programme across four vendors, skipping it is negligence.

Common mistakes to avoid

• Tracking only the predecessor. The receiving team’s readiness is half the dependency. Both sides need a name and a date.
• Recording dependencies without dates. “Waiting on design” is a status; “needs final copy by 12 March, promised 9 March, owners named” is a control.
• Treating a green board as a healthy plan. Progress on tasks says nothing about readiness at the seams.
• Letting the register live outside the work. If the dependency is not visible where people plan their day, it will be rediscovered in the post-mortem.

Where dependency tracking fits in your tooling

Most dependency failures are information failures, not analytical ones. The data exists — in a contract date, an email, a blocked ticket — but it is scattered across four systems, so nobody can see the chain.

Doitify models dependencies as part of the plan rather than as a side document: multi-level tasks and sub-tasks with owners and due dates, WBS dependencies on the schedule, Gantt and calendar views that show the wait, and workload views that expose resource dependencies before they become conflicts. Reports then answer the question that matters weekly — which chains are exposed and who owns each side.

Two honest limits, and Doitify is our product so weigh them here. It is not a substitute for a formal schedule risk analysis on a multi-vendor capital programme; that needs dedicated scheduling software and a planner. And a tool cannot make people name an owner — it can only make the absence obvious.

Conclusion

Dependency management is unglamorous and disproportionately valuable. The four relationship types give you the vocabulary, but the decisions come from the cause: mandatory and external dependencies need buffers, discretionary and resource dependencies need challenging.

Three habits carry most of the benefit. Name an owner on both sides of every dependency. Put a needed-by date and a promised date next to each other so the gap is visible. Then ask, every single time, whether the dependency can be removed rather than managed. Teams that ask that question ship earlier than teams that get very good at waiting.

If this post on dependency management was helpful, you might also enjoy Free Project Roadmap Template and How to Automate Project Reminders (Step-by-Step).