Task Dependencies in Project Management: The 4 Types and How to Keep Them Simple

A task dependency is a structural relationship between two activities that dictates the order in which work must happen. In any project schedule, one task often cannot begin or finish until another has started or finished. Establishing these connections creates an accurate sequence of delivery, reveals operational bottlenecks, and prevents team members from starting work before necessary prerequisites are in place.

Without explicit dependencies, a schedule is merely a detached list of dates. Best-practice frameworks such as the GAO Schedule Assessment Guide underline that a credible schedule must link every activity logically from project inception to completion. When dependencies are clear, adjusting the duration of an early task automatically shifts subsequent commitments, giving everyone an honest view of the delivery timeline.

What is a task dependency in project planning?

Every dependency connects two discrete units of work: a predecessor and a successor. The predecessor task controls the timing or conditions of the successor task. If the predecessor slips or finishes early, that change ripples directly through the successor.

Dependencies arise from four common project realities:

1. Physical and technical requirements: You cannot paint a wall before building the plasterboard partition, and you cannot test code before compiling the software package.
2. Resource constraints: A specialist editor or testing rig can only handle one assignment at a time, requiring sequential scheduling even if the tasks are technically independent.
3. Contractual and regulatory obligations: Formal sign-offs, legal verifications, or compliance inspections must conclude before operational deployment can proceed.
4. Discretionary choices: A team may decide as a matter of preference to conduct market research before writing copy, even though the copy could theoretically be drafted first.

Distinguishing between hard dependencies (physical or contractual limits) and soft dependencies (team preferences) is critical. When delivery pressure builds, soft dependencies can be re-evaluated or run concurrently, whereas hard constraints cannot be bypassed without compromising safety, quality, or legal standing.

What are the 4 logical types of task dependencies?

Project scheduling methodology identifies four standard dependency relationships. Each relationship determines whether the predecessor's start or finish dictates the successor's start or finish. Documentation such as the guide to linking tasks in a project from Microsoft Support details these four combinations.

1. Finish-to-Start (FS)

Finish-to-Start is the standard, most intuitive link in project scheduling. In this relationship, Task B cannot begin until Task A has finished.

For example, in digital publishing, you cannot begin proofreading an article until the author finishes writing the draft. Finish-to-Start represents the overwhelming majority of links in construction, software development, event planning, and creative operations. Because it creates an unambiguous handoff between collaborators, it forms the backbone of reliable planning.

2. Start-to-Start (SS)

In a Start-to-Start relationship, Task B cannot begin until Task A has started. Once Task A is underway, Task B may start and proceed in parallel.

For example, during a major database migration, the task «Monitor system performance» can start as soon as «Execute data transfer» starts. The monitoring does not have to wait for the entire transfer to conclude, but it makes no sense to begin monitoring before the migration process actually kicks off.

3. Finish-to-Finish (FF)

In a Finish-to-Finish relationship, Task B cannot finish until Task A has finished. Both tasks may run concurrently, but the successor cannot be wrapped up until the predecessor reaches completion.

For example, while rolling out a new enterprise software module, «Write user documentation» can proceed alongside «Develop software features». However, the technical writers cannot formally finish the documentation until developers finish implementing the final feature set.

4. Start-to-Finish (SF)

Start-to-Finish is the rarest and least intuitive dependency type. In this arrangement, Task B cannot finish until Task A starts.

A classic scenario involves continuous handover operations, such as security guarding or server infrastructure switchovers. An existing legacy server cannot finish operating until the new cloud cluster officially starts taking live traffic. The moment the new system starts running, the legacy system can finally be wound down and completed.

What are lead time and lag time?

Dependencies often require temporal adjustments beyond simple sequential linking. Project management expresses these adjustments as lead time and lag time.

Lag time represents an enforced delay between the predecessor and successor. It reflects waiting time where no direct labour is taking place. For example, after pouring concrete (Task A finishes), you might require a mandatory three-day curing lag before beginning wall framing (Task B starts). Similarly, submitting a grant application might involve a two-week regulatory waiting period before follow-up reviews can occur.

Lead time represents negative lag: an acceleration that allows the successor to start before the predecessor has completely finished. For instance, if laying out a 100-page catalogue takes four days, a graphic designer might establish a two-day lead time on proofreading, allowing the proofreader to review finished preliminary pages before the entire layout phase concludes.

While lead and lag appear convenient on paper, they add considerable maintenance overhead. Guidelines from the GAO Schedule Assessment Guide caution that excessive or undocumented lead and lag values obscure project clarity and complicate schedule health audits. A negative lag (lead) is often an artificial workaround for an activity that should have been split into two smaller, genuinely sequential tasks.

Software capabilities also vary widely. In Microsoft Planner, for example, editing lead and lag on a dependency requires a Planner Plan 3 subscription, as detailed in the Microsoft Tech Community guide on lead and lag (checked on 2026-09-29). In lightweight environments, simpler representations are often far easier to manage.

Why Finish-to-Start covers almost all day-to-day work

Many planning failures stem not from insufficient dependency modelling, but from over-modelling. When teams introduce dozens of overlapping Start-to-Start, Finish-to-Finish, and negative-lead relationships, the schedule becomes brittle. A minor delay in one activity triggers non-intuitive date changes across the Gantt chart, leaving project participants confused about when they actually need to carry out their work.

In standard team operations—such as marketing campaigns, engineering sprints, legal filings, and design projects—practically every genuine workflow dependency is Finish-to-Start. A person needs the output of one step before they can responsibly carry out the next. When tasks are scoped to reasonable durations (such as half a day to three days), there is rarely a need for complicated overlapping links.

If you find yourself tempted to use an overlapping Start-to-Start or lead link, splitting the predecessor into two smaller deliverables almost always produces a cleaner outcome. Instead of linking «Build website» and «Write website copy» with an overlapping lead, split the work into «Deliver website wireframes» (which copywriters wait for) and «Develop interactive components» (which relies on finalized copy). The resulting plan uses straightforward Finish-to-Start links, making responsibilities self-evident.

Worked example: scheduling a print run step by step

To see how sequential Finish-to-Start dependencies organise collaborative work without confusion, consider this practical example of producing an event brochure for commercial printing.

In this example, Ana handles the visual design and layout, Luis conducts the copy editing, and you handle the final pre-flight verification and dispatch to the print shop. The calendar runs Monday to Friday, with 6 hours of dedicated task work scheduled per person each working day. Each person works on one task at a time, and every step waits cleanly for the preceding deliverable to conclude.

Notice the practical mechanics revealed by this schedule:

1. Sequential allocation: Ana finishes the cover on Tuesday afternoon. Because «Lay out the brochure» waits for the cover design to finish, she begins the brochure layout on Wednesday morning. The 1½ days of layout work take Wednesday (6 hours) and half of Thursday (3 hours).
2. Immediate handoff: As soon as Ana completes the layout on Thursday at midday, Luis can begin «Review the copy». His half-day review (3 hours) completes on Thursday afternoon.
3. Calendar awareness: Because the working day ends once Luis finishes his review on Thursday, the final 1-hour verification and file transfer by you takes place first thing on Friday morning, concluding the project on Friday 16 October 2026.

If Ana were delayed by half a day on the cover design, every dependent task downstream would move naturally by half a day without requiring manual recalculation or renegotiating arbitrary lag offsets.

How to manage dependencies without getting bogged down

Managing project dependencies effectively requires adopting simple scheduling habits that protect your team from administrative friction.

Avoid circular dependencies

A circular dependency—also known as a dependency loop—occurs when Task A waits for Task B, Task B waits for Task C, and Task C is mistakenly set to wait for Task A. Circular dependencies create a mathematical deadlock: no task in the loop can ever start because each is waiting for another member of the circle to finish.

Modern project scheduling software identifies and blocks dependency loops immediately. If you encounter a situation that seems circular in real life, the issue is invariably task definition. One of the tasks contains two distinct stages of work that must be separated into an initial draft and a final sign-off.

Surface blocked work automatically

Team members should never spend their morning checking Gantt charts to figure out which activities are unblocked. An actionable project board ought to distinguish immediately between tasks that are ready for immediate execution and tasks waiting on predecessors.

This principle is built directly into tokidu, the project manager by Sinergia Barcelona. The platform intentionally focuses on Finish-to-Start relationships using a feature called «Starts when … is done». A dependent task remains visually and functionally blocked until the preceding task is completed. The moment the predecessor finishes, the successor unlocks automatically with a notification and surfaces in the team member's «Up next» view, showing only what can actually be worked on right now. If a predecessor is reopened, downstream items lock again automatically, preserving schedule integrity without manual checks.

Use dependencies alongside workload balancing

Dependencies define the logical order of deliverables, but human capacity determines how quickly work actually moves. A team member cannot execute two separate assignments simultaneously simply because both happen to be unblocked.

When evaluating scheduling tools, look for systems that combine dependency logic with realistic calendar availability. Platforms that feature dependency scheduling, such as timeline planners discussed in advanced project planning with Microsoft Planner, adjust task start dates based on the logical sequence of work. Similarly, when project schedules calculate dates automatically based on working calendars, team members are never scheduled for concurrent conflicting tasks, ensuring that deadlines remain honest and achievable.

Explore our dedicated guides on task dependencies and project sequencing to dive deeper into practical dependency structuring, buffer management, and critical path coordination.