Connect your tasks to model the real sequence of work.
Dependencies are the logical connections between tasks. They define "what must happen before what" — the sequence of work. Without dependencies, all tasks would start on day one, which rarely reflects reality.
When you add a dependency, you're saying: "This task can't start (or finish) until that other task reaches a certain point."
Most real-world work uses Finish-to-Start dependencies, but Consequent supports all four standard types for situations that require them.
Finish-to-Start (FS)
DefaultThe successor cannot start until the predecessor finishes.
Example: "Paint walls" cannot start until "Drywall installation" finishes.
Start-to-Start (SS)
The successor cannot start until the predecessor starts.
Example: "Pour concrete floor B" can start as soon as "Pour concrete floor A" starts (using the same crew).
Finish-to-Finish (FF)
The successor cannot finish until the predecessor finishes.
Example: "Testing" cannot finish until "Development" finishes — but they can proceed in parallel.
Start-to-Finish (SF)
The successor cannot finish until the predecessor starts.
Example: Rare in practice. Used for just-in-time scenarios: "Run old system" doesn't finish until "Start new system" starts.
We've made deliberate choices to keep dependency logic clear and auditable:
Consequent encourages explicit wait activities for clarity and reporting, while optionally supporting lag for compatibility with existing planning habits.
Task groups cannot be predecessors or successors
Summary tasks are structural. Their dates are derived from child tasks, so dependencies must connect leaf tasks to stay explicit and auditable.
Use child tasks or gate milestones instead
If a phase must finish before another starts, link the successor to a specific child task or a milestone like "Phase complete." This keeps intent visible.
Explicit wait activities preferred
Lag creates hidden time. Instead of "Task A + 3 days → Task B", create an explicit task: "Task A → Curing time (3d) → Task B". More verbose, but everyone can see and discuss it.
Dependencies are the logic of the schedule. When they are explicit, reviewers can trace cause and effect without guesswork.
Consequent avoids hidden bulk links (like parent-task dependencies) and hidden time (like implicit lag) so the schedule remains explainable as it grows.
The intuition is simple: "Finish Phase A before Phase B starts." A parent task seems like the phase, so making it the predecessor feels natural.
But a parent has no intrinsic work; its dates are derived from its children (start = earliest child start, finish = latest child finish). A dependency from a parent is therefore a hidden bulk expansion: Parent A → X really means A1 → X, A2 → X, A3 → X, and so on.
That creates a trap: adding or removing a child changes the dependency graph, and allowing overlap for one child becomes a logic mutation, not just a structural edit. Consequent keeps structure and logic separate by forbidding parent dependencies; link to specific child tasks or add an explicit gate milestone instead.
If a parent is the successor, which child is actually blocked? A strict interpretation means no child can start until the predecessor finishes (equivalent to linking every child). A loose interpretation means only "some" child is blocked, but there’s no consistent rule for which.
Because there is no stable, universally accepted meaning, parent-as-successor dependencies are inherently ambiguous. Consequent disallows them and requires explicit, task-level links.
Open the task that should be the successor (the dependent task).
In the Predecessors section, click Add Predecessor.
Select the predecessor task and choose the dependency type (FS is default).
Save. Consequent immediately recalculates dates.
Learn how SNET and FNLT constraints work in Consequent — they flag issues rather than silently blocking, giving you full visibility and control.
Date Constraints