What are Project Dependencies?

The Four Types of Dependencies

Project management defines four dependency relationships between tasks:

• Finish-to-Start (FS) — most common: Task B cannot start until Task A finishes. Design approval must finish before development starts.
• Start-to-Start (SS) — Task B cannot start until Task A starts. Testing documentation starts when development starts.
• Finish-to-Finish (FF) — Task B cannot finish until Task A finishes. Content writing must finish when design finishes.
• Start-to-Finish (SF) — rare: Task B cannot finish until Task A starts. Used in just-in-time scheduling.

Internal vs External Dependencies

Dependencies also come from outside the team, which adds risk:

How to Manage Dependencies

Dependencies are managed by making them visible and tracking them actively:

Map them at kickoff — as part of project planning, list all tasks and identify which ones depend on which others. External dependencies (waiting on the client, a vendor, another team) need particular attention.

Build buffer for external dependencies — tasks that depend on external inputs are higher risk because you don't control them. Add buffer time after external dependency tasks to absorb delays.

Communicate early — when a dependency task is at risk of slipping, tell dependent tasks' owners immediately. A 2-day slip in Task A might not delay the project if Task B has float, but the owner of Task B needs to know.

Use your task board — a project board that shows task status and dependencies gives everyone visibility into whether dependencies are met before work starts.

Dependency Map: How to Build One

A dependency map is a visual diagram showing all task relationships in a project — which tasks feed into which, where parallel paths exist, and where the critical chain runs.

Building one doesn't require specialized software. A whiteboard session at kickoff, a Miro board, or boxes and arrows in a slide deck can produce a functional dependency map.

Start with all major deliverables as boxes. Then draw arrows representing 'must finish before.' A finish-to-start dependency between Design and Development becomes an arrow from the Design box to the Development box. When you've mapped all the relationships, the longest connected path from start to finish is your critical path — visible at a glance.

Keep the map updated. When a new task is added or a dependency changes, update the map. A dependency map that's only accurate at kickoff creates false confidence.

• Draw all major tasks as boxes, then connect them with dependency arrows
• The longest connected path from start to finish is the critical path
• Keep diagrams under 40 nodes — split by phase for larger projects
• Update the map when tasks are added or dependency relationships change

External Dependencies: Managing Client-Side Delays

External dependencies are the most dangerous kind — they're outside your control but on your critical path. The most common: waiting for the client to provide content, approve a deliverable, or complete a task before you can proceed.

Four practices reduce the damage from external dependencies:

First, name them explicitly in the project plan. Every task that requires client input should be flagged as an external dependency with an expected response time.

Second, build timeline buffer after external dependencies. If approval takes 3 days in the plan, build 5 days of buffer before the next task starts.

Third, send reminder communication before the deadline. A reminder 48 hours before the client content deadline is far more effective than a follow-up after it's missed.

Fourth, include external dependency language in your contracts. If the client fails to deliver content on schedule, the project timeline adjusts accordingly.

• Name every external dependency explicitly in the project plan with expected dates
• Build buffer time after external dependency tasks — plan for the likely delay
• Send reminders 48 hours before client deadlines, not after they're missed
• Include contractual language: client delays adjust the project timeline

Dependency Tracking in Practice

Knowing your dependencies at kickoff is step one. Tracking them throughout the project is where most teams fall short.

Dependency tracking means knowing, at any point in the project, the status of every dependency on the critical path. For each dependency: Is the predecessor task on schedule? If it slips, which downstream tasks are affected?

Practically, this requires two things. First, your task management system needs dependency relationships modeled — not just a flat task list. When Task A has a formal dependency link to Task B, a slip in Task A should surface as a risk to Task B automatically. Second, someone needs to own the dependency review. For projects with 10+ interdependent tasks, a weekly 15-minute dependency check where the PM looks at all tasks due in the next two weeks catches problems before they cascade.

The most useful question in every weekly project review: are all tasks scheduled to start in the next 7 days unblocked? If a task is due to start Monday and its predecessor isn't done yet, you have a dependency problem that needs resolution today.

• Model dependencies in your task tool — don't just track them in a document
• Weekly check: are all tasks starting next week fully unblocked?
• Calculate float for each dependency — how much slip is tolerable before cascade?
• Assign one owner to dependency tracking on each project (usually PM)