Every project is a web of interconnected tasks. Miss one thread, and the whole thing unravels. Dependency management isn't glamorous, but it's the difference between projects that flow and projects that stall.

Why Dependencies Matter More Than You Think

A dependency exists whenever one task cannot start or finish without another task reaching a certain state. Simple in theory. Devastating in practice when overlooked.

Consider a software deployment: you can't release to production until testing completes, testing can't start until development finishes, and development can't begin until requirements are signed off. Miss any link in this chain, and your go-live date becomes fiction.

The real danger isn't the obvious dependencies—it's the hidden ones. The API your team assumes will be ready. The approval that "should only take a day." The resource who's also committed to three other projects. These invisible threads are what strangle projects.

Types of Dependencies You Need to Track

Not all dependencies behave the same way. Understanding the types helps you manage them appropriately:

Finish-to-Start (FS): The most common type. Task B cannot start until Task A finishes. Foundation must be complete before walls go up.

Start-to-Start (SS): Task B cannot start until Task A starts. Testing can begin once development starts (testing the first completed modules while others are still being built).

Finish-to-Finish (FF): Task B cannot finish until Task A finishes. Documentation cannot be finalised until the feature it describes is complete.

Start-to-Finish (SF): Rare, but exists. Task B cannot finish until Task A starts. The old system cannot be decommissioned until the new system goes live.

Beyond timing relationships, consider the nature of each dependency:

  • Mandatory: Physically or contractually required. You cannot test software that doesn't exist.
  • Discretionary: Best practice but flexible. You prefer to complete design before development, but could prototype in parallel if needed.
  • External: Outside your control. Waiting for vendor delivery, regulatory approval, or a client decision.
  • Internal: Within your organisation. Another team's deliverable, shared resource availability, or internal sign-off.

Common Dependency Management Mistakes

After years of project recovery work, certain patterns emerge repeatedly:

Assuming verbal commitments are reliable. "They said it would be ready by Friday" is not dependency management. Get commitments in writing, with clear deliverables and acceptance criteria.

Ignoring external dependencies until they bite. Third-party dependencies deserve more attention, not less. You have zero control over their delivery, so you need earlier visibility and contingency plans.

Treating the critical path as static. Your critical path shifts as the project progresses. A delay on a non-critical task can suddenly make it critical. Review dependencies weekly, not just at planning.

Failing to distinguish between dependency and preference. When everything is marked as dependent, nothing is. Be rigorous about what truly cannot proceed versus what you'd simply prefer to have first.

Not communicating dependency status. The team working on Task A may not realise three other teams are blocked waiting for them. Make dependencies visible to everyone involved.

Practical Techniques for Tracking Dependencies

Theory is worthless without practical application. Here's what actually works:

Create a dependency register. A simple spreadsheet works: Source Task, Dependent Task, Type, Owner, Due Date, Status, Risk Level. Update it weekly. Share it widely.

Use network diagrams. Visualising dependencies as a network reveals the critical path and highlights bottlenecks that aren't obvious in a task list. Tools like Microsoft Project or even Miro can help.

Hold dependency reviews. In your weekly status meetings, explicitly ask: "What are you waiting on? What's waiting on you?" This surfaces issues before they become blockers.

Add buffer to external dependencies. If a vendor says two weeks, plan for three. If legal says one review cycle, plan for two. External dependencies almost always take longer than promised.

Identify dependency owners. Every cross-team dependency should have a single person accountable for tracking and escalating. Shared ownership means no ownership.

Handling Conflicts and Risks

When dependencies conflict or risk the schedule, act decisively:

Escalate early. A dependency at risk is a project at risk. Don't wait until the deadline passes to raise the alarm. The moment you see slippage, communicate upward.

Explore alternatives. Can you resequence work? Start with a different module? Use a stub or mock while waiting for the real component? Parallel paths often exist if you look for them.

Negotiate scope. If a dependency cannot be met in time, what's the minimum viable version that would unblock progress? A partial deliverable may be enough to keep moving.

Document decisions. When you accept a delay or change the plan due to dependencies, record why. This protects everyone when questions arise later.

The Bottom Line

Dependency management is unglamorous work. There's no framework with a catchy acronym, no certification to hang on your wall. But it's the plumbing of project management—invisible when it works, catastrophic when it fails.

Start with visibility. Map your dependencies. Review them regularly. Communicate relentlessly. The web of interconnections will always exist. Your job is to see it clearly and keep it from choking your project.