Dependencies

Dependencies define the logical sequencing of work: task B cannot start until task A reaches a defined state. DPlan supports all four standard relationship types — FS, SS, FF, SF — with optional lag (delay) or lead (overlap). Dependencies are visualised as arrows on the Gantt, can be created by dragging directly between bars, and drive the Auto Schedule calculation.

What Dependencies Are

A dependency (also called a precedence relationship or link) connects two tasks so the scheduler knows their relative order. DPlan supports all four PMI-standard relationship types:

Type	Plain English	Meaning
FS	"right after"	Successor starts after predecessor finishes (most common)
SS	"starts together"	Successor starts when predecessor starts
FF	"finishes together"	Successor finishes when predecessor finishes
SF	"inverse"	Successor finishes when predecessor starts (rare)

FS handles ~95% of real-world sequencing. The other types exist for cases where the predecessor and successor share a start or end boundary (e.g. parallel kickoff, joint completion).

Adding a Dependency — Drag-to-Connect (recommended)

The fastest way to link two tasks is to drag from a handle on one bar to another bar:

Hover any task bar. Two small handles appear: ● green at the start and ● blue at the end.
Press and drag from a handle. A ghost arrow follows the cursor and a floating chip shows the dependency type as you move — for example, FS · "right after".
Drop on another bar. The dependency type is inferred from the source handle and the half of the target bar where you released:
- End → start half = FS (right after)
- End → end half = FF (finishes together)
- Start → start half = SS (starts together)
- Start → end half = SF (inverse)
Release. A toast confirms the link and the arrow appears on the Gantt instantly.

During the drag, the chip turns red if releasing on that bar would create a circular dependency. The drop is silently rejected — no error toast, just immediate visual feedback. You never need to undo a circle.

Adding a Dependency — Task Editor (alternative)

Drag-to-connect is fastest, but the Task Editor still works if you prefer a list-based flow or are setting up many predecessors at once:

Double-click the successor task (the task that must wait) to open its Task Editor.
Scroll to the Dependencies section.
Pick a predecessor from the dropdown and click Add. The Task Editor flow always creates an FS dependency with lag 0 — to use SS/FF/SF or set a lag, edit the arrow on the Gantt afterwards (see below).
Click Save (or press Ctrl+Enter).

Adding a Dependency — Dependencies Column (MS Project syntax)

The Gantt task list has a Dependencies column between End and Prog. Click any cell and type a comma-separated list of predecessors using MS Project syntax. The cell becomes editable in place — no modal, no dropdown.

Type	Example	Means
Bare row #	`5`	Predecessor at row 5, FS, no lag
Type only	`5SS`	Row 5, Start-to-Start, no lag
Type + lag	`5FS+2d`	Row 5, FS, +2 working days
Type + lead (negative lag)	`3FS-1d`	Row 3, FS, 1 working day overlap
Multiple predecessors	`1, 2SS-1d, 7FF`	Three preds, comma-separated

Input is permissive — 5fs+2d, 5 FS + 2 d, 5FS+2D all parse the same. On save, the cell normalises to canonical form (uppercase type, lowercase d): 5FS+2d.

Validations on save:

Self-reference rejected (a task can't depend on itself)
Non-existent row numbers rejected ("Row 99 does not exist")
Cycles rejected before the dep is saved ("That would create a cycle")

Auto-snap to earliest valid position (ASAP): When you save a new dep, the successor task is automatically moved to the earliest valid date based on all its predecessors (latest binding constraint wins). Matches MS Project's default scheduling. Anchored tasks (📌) and descoped tasks are never moved.

The # column shows sequence numbers (1, 2, 3…) which is what the Dependencies column references — the two columns always stay in sync. Reordering tasks updates the displayed numbers but the underlying links remain intact (they reference task IDs, not row positions).

The Dependency Arrow on the Gantt

Each dependency is rendered as an elbow-routed arrow on the SVG Gantt. The arrow colour communicates the lag/lead status at a glance:

Arrow Colour	Meaning
Grey	Zero lag — successor starts immediately when predecessor reaches its anchor point
Orange / Amber	Positive lag — there is a waiting period built into the link
Blue	Negative lag (lead) — overlap; successor begins before predecessor reaches its anchor
Red (cascade)	Briefly highlighted after a Smart Reschedule cascade pushes successors

Editing or Deleting a Dependency — the Pill Editor

Click any arrow on the Gantt to open an inline pill editor anchored at the click point. No modal, no view switch.

Type — four buttons (FS / SS / FF / SF). Click to switch; the arrow updates instantly.
Lag — a numeric stepper with − and + buttons. Positive = delay, negative = lead. Press Enter in the input to commit and close.
Delete — a 🗑 button at the bottom right removes the dependency immediately.
Close — click outside the pill or press Esc.

A subtitle inside the pill shows the dependency in plain English: "right after · +3d", "starts together", "finishes together · -2d". This is the same vocabulary used by the chip during a drag — consistent everywhere.

Lag — Delay After Predecessor

Lag introduces a mandatory waiting period between when the predecessor finishes and when the successor can start. Lag is expressed in working days.

Examples of lag:

Concrete curing: After "Pour Foundation" finishes, "Build Framing" cannot start for 7 days while the concrete cures. Set lag = 7 on the FS dependency.
Client approval: After "Submit Design Proposal" finishes, allow 3 days for client review before "Begin Implementation" starts. Set lag = 3.
Regulatory processing: After "Submit Application" finishes, the regulator requires 20 business days to respond. Set lag = 20 on any successor task.
Shipping lead time: After "Order Equipment" finishes, allow 10 days for delivery before "Install Equipment" can start. Set lag = 10.

In the Auto Schedule forward pass, a lag of N days adds N working days between the predecessor's EF and the successor's ES.

Lead — Overlap (Negative Lag)

Lead allows a successor task to begin before its predecessor has fully completed. Lead is entered as a negative number in the lag field. Lead represents an overlap assumption — the premise that the successor can safely begin with partial output from the predecessor.

Examples of lead:

Parallel documentation: Technical writing can begin 3 days before development finishes (writers can draft based on partially completed features). Set lag = −3.
Staged handoff: Testing can begin 5 days before coding finishes if the team delivers completed modules incrementally. Set lag = −5.
Fast-tracking the critical path: If "Design" and "Prototype" are sequential on the critical path, introduce −2-day lead to compress the schedule by 2 days, accepting the risk that design changes late in the design phase will require prototype rework.

Lead introduces schedule risk. If the predecessor task slips or its output changes during the overlap period, the successor may need to be reworked. Always document the risk assumption in the successor task's Notes field when using significant lead values.

Multiple Predecessors

A task can have any number of predecessors. Auto Schedule takes the maximum of all predecessor Early Finish dates (adjusted for lag) as the task's Early Start. This is the "all must finish" merge logic — the successor cannot begin until the last predecessor has finished.

Example: "User Acceptance Testing" has three predecessors: "Core Features Complete" (lag 0), "Test Data Ready" (lag 0), and "Test Environment Configured" (lag 1 day). Testing starts the day after the last of these three is complete. If Core Features finishes on Day 20, Test Data on Day 18, and Test Environment on Day 19 (+1 lag = effective Day 20), then UAT starts on Day 20.

Removing a Dependency

The fastest way: click the arrow on the Gantt → click the 🗑 Delete button in the pill editor. The arrow disappears immediately and a toast confirms.

Alternative: open the successor task's editor, find the predecessor chip in the Dependencies section, and click × on the chip.

Removing a dependency is undoable — press Ctrl+Z to restore it.

Circular Dependency Detection

DPlan checks for circular dependencies (A → B → C → A) at three points:

Live during drag-to-connect — the moment your cursor enters a bar that would create a cycle, the ghost arrow and chip turn red and the chip reads "circular — not allowed". Releasing there is silently rejected. You see and feel the rejection before you commit.
At Task Editor add time — the dependency is rejected with a toast: "Circular dependency detected — cannot add."
At Auto Schedule time — scheduling halts and an error message lists the tasks involved in the cycle.

To resolve a circular dependency, identify which link in the chain is logically incorrect and remove it. Most circles are caused by accidentally connecting the last task in a phase back to the first task, or by copying/pasting dependency data incorrectly.

How Auto Schedule Uses Dependencies

Dependencies are the primary input to the CPM scheduling algorithm. Without dependencies, all tasks are independent and Auto Schedule can only set each task to its constraint date (or project start if ASAP). The more completely your dependency network reflects real-world sequencing logic, the more useful Auto Schedule's output will be.

See Scheduling for the full algorithm detail, and Critical Path for how dependency chains produce the critical path.

Practical Dependency Patterns

Pattern 1 — Sequential Chain

The simplest and most common pattern: A → B → C → D. Each task waits for the previous one to complete. Use this for work where each phase produces a deliverable the next phase consumes.

Requirements (5d) → Design (8d) → Build (15d) → Test (5d) → Deploy (1d)

The entire chain forms the critical path if no parallel work exists.

Pattern 2 — Parallel Work with Merge

Multiple independent work streams converge at a merge point — typically a milestone or an integration task.

Frontend Dev (10d) ──┐
Backend Dev  (12d) ──┼→ Integration Testing (5d) → Launch
API Design    (3d) ──┘

The merge task (Integration Testing) has three predecessors. Auto Schedule sets its start to the latest finish of the three parallel tracks. The longest parallel track (Backend Dev at 12d) defines when integration can begin.

Pattern 3 — Phase Gate Milestone

All tasks in a phase feed into a milestone, and the next phase begins after the milestone.

Task A ──┐
Task B ──┼→ [Phase 1 Gate Milestone] → Task D (Phase 2 start)
Task C ──┘

Set the milestone's constraint to MSO if the gate review is on a fixed date. See Milestones for full detail on this pattern.

Pattern 4 — Lag for External Wait

Use lag wherever an external process introduces a mandatory wait: regulatory approval, shipping, curing, legal review, client sign-off cycles.

Submit for Patent Review → [lag: 90 days] → Begin Manufacturing Scale-Up

Pattern 5 — Lead for Fast-Track Overlap

Use negative lag to compress the critical path by overlapping tasks where technically feasible.

Content Writing (10d) → [lead: -3d] → Content Review (5d)

Review begins 3 days before writing completes — reviewers start on early chapters while writers finish later ones.

Best Practices

Model all real constraints as dependencies. If task B genuinely cannot start until task A finishes, express that as a dependency — do not just manually set dates. Manual dates break when Auto Schedule runs; dependencies are permanent and self-maintaining.
Use milestones as merge points. When many tasks converge, using a milestone as the merge point rather than making one task dependent on all others keeps the dependency network cleaner and the Gantt less cluttered.
Keep lag values meaningful. If you add a 5-day lag, document why in the Notes field of the successor task. Unexplained lags become mysteries months later.
Review dependency arrows after every major restructure. When you move tasks between phases or delete tasks, orphaned dependency references may remain. Check the Gantt for arrows pointing to unexpected locations.
Do not use dependencies as a substitute for phases. Dependencies show sequencing; summary phases show hierarchy. Use both: phases for WBS structure, dependencies for scheduling logic.
Limit the use of lead. Lead is a schedule compression tool, not a default modelling technique. Each lead assumption is a risk. Document it, communicate it to the team, and monitor the overlap period actively.