How to schedule task dependencies
Build a sequence in which every activity starts and finishes according to a real enabling condition—not an arbitrary date, habit or visually convenient calendar position.
What a task dependency means
A task dependency is a logical relationship between activities. It describes how the start or finish of one activity affects the permitted start or finish of another. The activity that provides the enabling condition is the predecessor. The activity that relies on that condition is the successor.
Dependencies make a schedule responsive. When a predecessor finishes late, the dates of connected successors can move. When work finishes early, a valid network can show whether later activity may begin sooner. Without these relationships, a schedule is merely a collection of manually entered dates.
Dependencies should represent actual work logic. “Manager prefers Tuesday” is not automatically a dependency. “Final approval must be received before publication begins” is a dependency because publication relies on a defined predecessor result.
A dependency is also different from a constraint. A dependency connects two activities or events. A constraint restricts an activity to a date or timing boundary. Using date constraints in place of logical connections may make the schedule appear orderly while hiding the real effect of delay.
Not every task must wait for the previous task to finish completely. Some work can proceed in parallel, some can begin after a stable partial output exists, and some activities must finish together. The chosen relationship should express that real condition without creating unnecessary complexity.
Four common task-dependency relationships
Finish-to-start
The successor cannot start until the predecessor finishes. This is the clearest and most common relationship when one completed output enables the next activity.
Example: testing starts after implementation finishes.
Use it when the complete predecessor result is genuinely required. Do not use it automatically when a verified partial output can support safe parallel work.
Start-to-start
The successor cannot start until the predecessor starts. The two activities do not necessarily begin simultaneously; the relationship establishes an earliest permitted sequence.
Example: progress monitoring begins after fieldwork starts.
Use carefully. If the successor actually requires a measurable portion of predecessor work, represent that partial deliverable explicitly where practical.
Finish-to-finish
The successor cannot finish until the predecessor finishes. Work may proceed concurrently, but one activity cannot be considered complete before the other reaches its finish condition.
Example: final documentation cannot finish before implementation finishes.
Define what information transfers at completion. An unexplained finish-to-finish link can hide the production work connecting the activities.
Start-to-finish
The successor cannot finish until the predecessor starts. This relationship is uncommon and can be difficult for readers to interpret.
Possible example: an outgoing coverage period ends only after replacement coverage begins.
Prefer a clearer activity breakdown where possible. Do not use this relationship merely to force a preferred date.
| Type | Required condition | Good question | Common misuse |
|---|---|---|---|
| Finish-to-start | Predecessor finishes before successor starts. | Does the successor require the entire predecessor output? | Serializing work that could proceed independently. |
| Start-to-start | Predecessor starts before successor starts. | What stable condition allows the successor to start? | Hiding a partial handoff or measurable intermediate output. |
| Finish-to-finish | Predecessor finishes before successor finishes. | Why can the successor not be completed independently? | Connecting dates without identifying the final information transfer. |
| Start-to-finish | Predecessor starts before successor finishes. | Is this truly a replacement or transition condition? | Using unusual logic to manufacture a desired schedule. |
Where schedule dependencies come from
Product dependencies
A successor needs a deliverable produced by earlier work: approved requirements, a completed design, prepared data, delivered materials or tested equipment.
Decision dependencies
Work cannot proceed until an authorized person selects an option, approves expenditure, accepts a result or resolves a scope question.
Resource dependencies
Activities depend on a specialist, room, machine, system, vehicle, platform or another limited resource becoming available.
External dependencies
A supplier, customer, authority, partner or separate project controls an input needed by the schedule.
Access dependencies
Work requires credentials, permissions, site entry, account activation, environment readiness or approved data access.
Calendar dependencies
A successor relies on operating hours, shift coverage, a review meeting, delivery service or another time-limited availability window.
How to schedule task dependencies step by step
Define the completion outcome
Identify the final deliverable, acceptance event or operational condition. Dependencies cannot be evaluated properly when the intended result remains vague.
List executable activities
Break the outcome into activities that consume time and produce observable results. Avoid summary labels such as “implementation” when they hide configuration, testing, review and handover.
Define each completion condition
State what proves every activity is finished. A percentage estimate is weaker than an accepted document, completed installation, verified test or recorded decision.
Ask what enables every activity
For each activity, identify the information, result, access, resource, decision or event that must exist before it can begin or finish.
Name predecessor and successor
Record both sides of each relationship. Activities with no predecessor or successor deserve review unless they are legitimate schedule boundaries.
Select the simplest accurate relationship
Prefer clear finish-to-start logic when the full predecessor output is required. Use other relationship types only when they describe actual execution more accurately.
Represent meaningful partial handoffs
If a successor can begin after part of the predecessor is stable, identify that intermediate result. This is often clearer than an unexplained start-to-start relationship with a long lag.
Add external interfaces
Include deliveries, approvals, permits, customer inputs and cross-project handoffs. Record who controls them, when they were requested and how status will be confirmed.
Apply realistic durations and calendars
Logic determines sequence; duration and calendars determine dates. Include working days, shifts, holidays, processing windows and resource availability.
Check resource feasibility
Parallel logic is not executable when both activities require the same unavailable specialist, machine or location. Resolve capacity conflicts before approving dates.
Validate major handoffs
Ask both the delivering owner and receiving owner to confirm the output, format, completion evidence, timing and acceptance process.
Test schedule movement
Move a predecessor forecast temporarily and observe whether affected successors respond correctly. A dependency that does not transmit consequences may be missing or overridden.
Review open ends and circular logic
Resolve ordinary activities without predecessors or successors. Remove loops in which Activity A depends on B while B ultimately depends on A.
Publish ownership and monitoring rules
Name who updates each important interface, how delays are communicated and when an alternative or escalation must be activated.
Task-dependency sequence checker
Enter one relationship per line using the format Predecessor > Successor. The checker builds a possible execution order, identifies starting and finishing activities and warns if the entered relationships contain a circular dependency.
This local checker evaluates basic directional logic only. It does not calculate dates, durations, calendars, leads, lags, resources, float or critical paths.
Make dependencies usable between people and teams
Define the output
Name exactly what the predecessor provides. “Send information” is weaker than “send the approved product list in the agreed spreadsheet format.”
Define acceptance
The receiving owner should know how to determine that the handoff is complete, usable and authorized. Delivery without acceptance may leave the successor blocked.
Assign both owners
Record the provider and receiver. Shared ownership without named responsibility often produces late discovery that each group expected the other to act.
Set the required-by point
Connect the handoff to the successor’s planned need date. Distinguish an internal target from the latest point that preserves downstream work.
Choose a status method
Use controlled states such as not requested, requested, confirmed, at risk, received, rejected and accepted. Avoid vague descriptions that cannot drive action.
Create an exception route
Define what happens when the handoff is late or unusable: clarification, correction, alternative source, temporary workaround, escalation or approved reforecasting.
Dependency problems that damage a schedule
Missing predecessors
Work appears able to begin immediately even though inputs, approvals or resources are required.
Missing successors
Delay stops propagating because the activity is not connected to the outcome it supports.
Circular dependencies
A chain eventually depends on itself, so no valid activity can begin without breaking the loop.
Duplicate logic
Several links express the same condition, making updates harder to interpret and maintain.
Logic based on ownership
Tasks are connected because the same person performs them, even when no output dependency exists. Model resource availability separately.
Excessive lags
Long waiting periods hide processing, curing, delivery or review that would be clearer as visible activities.
Artificial date constraints
Fixed dates replace predecessor-successor logic and prevent delay from flowing naturally through the schedule.
False parallel work
Activities appear concurrent but compete for the same limited person, facility, equipment or approval authority.
Unverified external promises
A supplier or reviewer date is treated as guaranteed without confirmation, ownership or a response plan.
Dependency examples in practical schedules
| Situation | Predecessor | Successor | Important validation |
|---|---|---|---|
| Website release | Release candidate passes agreed testing. | Production deployment is authorized. | Define which tests must pass and who authorizes release. |
| Employee onboarding | Required account and access preparation is complete. | Role-specific system practice begins. | Account existence does not prove correct permissions. |
| Event preparation | Final attendance quantity is approved. | Materials are produced. | Determine whether production can begin from a stable preliminary quantity. |
| Study plan | Foundation topic is reviewed and checked. | Advanced practice begins. | Use evidence of readiness rather than hours spent alone. |
| Procurement | Purchase authorization is issued. | Supplier order is placed. | Confirm required documentation, owner and supplier cutoff. |
| Document publication | Final factual and editorial approval is recorded. | Publishing and verification begin. | Keep revision time before the approval milestone. |
These examples describe logical relationships rather than universal requirements. Every schedule should use the completion conditions, approval routes and records appropriate to its actual context.
Monitor dependencies after work starts
Update actual progress accurately
Record actual starts, finishes and realistic remaining durations. A predecessor reported as complete prematurely can release successor work before its required input is usable.
Review the next handoffs
Focus on interfaces due before the next schedule update. Confirm the output, provider, receiver, forecast, acceptance condition and recovery option. A broad status meeting should not replace direct coordination between affected owners.
Recalculate downstream effects
When a dependency moves, identify every affected successor and milestone. Do not update only the first visible activity. A delayed approval may affect procurement, implementation, testing, training and final delivery.
Control logic changes
Revise a relationship when the execution method genuinely changes or the original logic was incorrect. Record the reason. Removing logic simply to protect a displayed date makes the schedule less reliable.
Watch near-term external interfaces
External dependencies deserve active confirmation. Track the request, acknowledged commitment, forecast, evidence received and fallback. Silence should not be interpreted as confirmation.
When a dependency affects ordinary weekly commitments, place its request, review or follow-up into the Weekly Schedule Builder. For longer sequences, use the Monthly Schedule Builder while retaining the underlying dependency record.
Task-dependency checklist
- The schedule has a clearly defined start and completion boundary.
- Every normal activity has an appropriate predecessor and successor.
- Each relationship expresses a real enabling condition.
- The simplest accurate dependency type has been selected.
- Partial handoffs are represented through measurable outputs where practical.
- External inputs, approvals and deliveries are visible.
- Provider and receiver ownership is clear for major handoffs.
- Completion and acceptance conditions are documented.
- Long lags have been reviewed for hidden work or waiting time.
- Date constraints do not replace valid schedule logic.
- Parallel activities have sufficient people and resources.
- No activity chain contains circular logic.
- Known delays propagate to the affected successor activities.
- Actual completion is recorded only when the required output exists.
- Logic changes are authorized, explained and recalculated.
- Critical external dependencies have monitoring and fallback arrangements.
Task-dependency FAQs
What is a task dependency in simple terms?
It is a relationship showing that one activity relies on the start, finish or output of another activity. The dependency helps the schedule calculate how timing changes affect later work.
What is the most common dependency type?
Finish-to-start is commonly used because it clearly expresses that one activity must finish before another can start. Use it only when the successor genuinely requires the completed predecessor result.
Can two dependent tasks overlap?
Yes, when the real work permits overlap. A successor might begin after a stable partial output becomes available. Define that handoff clearly instead of assuming that overlapping dates make the relationship valid.
Is a deadline a dependency?
A deadline is a timing boundary. A dependency is a logical connection between activities or events. A deadline may influence the schedule, but it should not replace the relationships showing how work reaches completion.
What is an external dependency?
It is an input or event controlled partly or completely outside the schedule owner’s direct authority, such as supplier delivery, customer approval or government response. Assign an internal monitoring owner even when another party controls completion.
What is a circular dependency?
It occurs when an activity depends directly or indirectly on itself. For example, A requires B, B requires C and C requires A. The loop must be corrected or no valid starting sequence exists.
Should every activity have a predecessor?
Most normal activities should have logical connections. Legitimate schedule-start activities may not require predecessors, while final completion milestones may not require successors. Unexplained open ends should be reviewed.
Are resource conflicts the same as dependencies?
Not always. Two independent tasks may compete for the same person or equipment without having a product dependency. Represent the work logic accurately and perform a separate resource-feasibility check.
When should a dependency be changed?
Change it when approved scope or execution methods change, or when validation shows the original relationship was incorrect. Record the reason and recalculate affected dates and paths.
How are dependencies related to the critical path?
Dependencies form the network through which the critical path is calculated. Missing, incorrect or artificial relationships can produce a misleading critical path and unreliable float values.
Make every connection explainable
A dependable schedule does more than display dates. It explains why work appears in a particular order and how a change in one activity affects the rest of the plan.
Define executable activities, identify their required inputs and outputs, connect predecessors with successors and select the simplest relationship that accurately represents the work. Make external dependencies and major handoffs visible rather than leaving them in messages or memory.
Validate the network with the people performing and receiving the work. Test whether delays propagate, resolve circular logic and open ends, confirm resource feasibility and control later logic changes.
Once these relationships are trustworthy, the schedule can support meaningful milestone forecasts, float calculations and critical-path analysis instead of presenting dates that must be corrected manually whenever reality changes.