How do I create a finish-to-start dependency with dates in a project schedule

TL;DR: Most guides define finish-to-start dependencies and move on. This one walks IT project managers through a dated, real-world example, a five-step setup process, and the two mechanics most schedules get wrong: lag time and milestone anchoring. You'll leave with something you can map into your next project schedule today.

What a finish-to-start dependency actually means

A finish-to-start dependency means one task must finish before the next one can start. That's it. Task B cannot begin until Task A is complete — no exceptions unless you explicitly add lag or lead time.

It's the most common of the four task dependency types:

• Finish-to-Start (FS): Task B starts after Task A finishes. The default in most scheduling tools, including Microsoft Project, which applies FS automatically when you link two tasks without specifying a type.

• Start-to-Start (SS): Task B can start once Task A starts, but both run in parallel.

• Finish-to-Finish (FF): Task B must finish by the time Task A finishes.

• Start-to-Finish (SF): Task B cannot finish until Task A starts. Rare in practice.

Most project schedule dependencies you'll configure are FS. The reason is straightforward: sequential work is the norm in IT projects. You can't test code that hasn't been written. You can't deploy a build that hasn't passed QA.

Where teams get into trouble is treating FS as a set-and-forget setting. The predecessor's finish date directly controls the successor's start date, so any slip upstream cascades immediately downstream. Understanding that relationship before you build the schedule is what separates a plan that holds from one that falls apart in week two.

For a deeper look at mapping these relationships visually, see how to create a dependency diagram for your project.

A finish-to-start example with real dates

Take a three-task software deployment sequence and the mechanics become immediately clear.

Task 1 — Environment setup: starts May 1, finishes May 7. Task 2 — Application deployment: the predecessor task is Task 1, so deployment cannot begin until May 8 at the earliest. That's a clean finish-to-start dependency with no lag. Task 3 — User acceptance testing (UAT): depends on Task 2 finishing. If deployment runs May 8–14, UAT starts May 15.

Now add a two-day lag between deployment and UAT — a common buffer that gives the environment time to stabilize before testers log in. UAT's start date shifts from May 15 to May 17. On a Gantt chart dependency view, you'd see the UAT bar move two days to the right, with a line connecting the end of Task 2 to the start of Task 3.

The formula is straightforward: Successor start = Predecessor finish + lag time. May 14 (finish) + 2 days (lag) = May 17 (start).

This is also where a finish-to-start milestone earns its value. If May 7 is a hard milestone — say, a client sign-off on the environment — missing it by even one day pushes every downstream task automatically. That cascade is exactly what the four types of project dependencies are designed to make visible before the delay happens, not after.

When you link tasks with a finish-to-start relationship in Taro, adding lag is a single field on the dependency record. Change the lag from 0 to 2, and the tool will recalculate your project's finish date automatically across every affected successor — no manual date hunting required.

How to set up a finish-to-start dependency in 5 steps

Setting up a finish-to-start dependency correctly takes about five minutes once you know the exact fields to fill in. Here is the repeatable process, using the software deployment example from the previous section as the working reference.

1. Identify the predecessor task and confirm its finish date: Start with the task whose completion gates everything downstream. In the deployment example, that is "Environment Configuration," finishing on June 12. Write that date down explicitly — it becomes the anchor for every calculation that follows. If you are unsure which task qualifies as the predecessor task, ask: "Can the next task start if this one is still running?" If the answer is no, you have your predecessor.

2. Identify the successor task and record its required inputs: The successor is the task that cannot begin until the predecessor finishes. In this case, it is "Smoke Testing," which needs a fully configured environment before any test can run. Note what the successor actually requires on day one, not just a vague dependency label. This forces you to validate that the relationship is real, not assumed.

3. Set the dependency type to finish-to-start (FS): In most scheduling tools, including Microsoft Project and Jira, FS is the default dependency type when you link two tasks. Still, confirm it explicitly. A finish-to-start dependency means the successor's start date equals the predecessor's finish date, or the predecessor's finish date plus any lag. Selecting the wrong type here (start-to-start, for example) will silently shift your entire schedule without an obvious error message. For a full picture of the four types of project dependencies, review those before wiring up a complex schedule.

4. Add lag time if a gap is required between tasks: Lag is the mandatory wait between the predecessor finishing and the successor starting. If your team needs 48 hours after Environment Configuration completes before Smoke Testing can begin, enter a lag of 2 days. The successor's start date shifts from June 13 to June 15. This is the step most teams skip, which is exactly why a finish-start with dates example looks clean on paper but breaks in practice when handoff time is not accounted for. Lag is not padding — it is a real constraint, and it belongs in the schedule.

5. Validate the dependency chain end to end: After linking the tasks, check that the successor's start date matches the predecessor's finish date plus lag. Then trace the chain forward: if the predecessor slips by three days, does the successor's start date move automatically? It should. Tools that recalculate your project's finish date automatically will cascade the shift across all downstream tasks, which is how you catch a one-day slip before it becomes a two-week delay.

Once all five steps are complete, you have a working finish-to-start dependency with hard dates anchoring both ends. You can then build the full project timeline around your dependencies or link tasks with a finish-to-start relationship in Taro if you want the cascade logic handled automatically.

How to read a finish-to-start dependency on a Gantt chart

On a Gantt chart, a finish-to-start dependency appears as an arrow connecting the right edge of one bar (the predecessor) to the left edge of the next (the successor). The arrow tells you: this task cannot begin until that one ends.

The cascade effect is where most teams get caught out. If your predecessor task runs from June 2 to June 9, and you add a 2-day lag, the successor bar automatically starts June 11, not June 9. Shift the predecessor by three days due to a delay, and the successor moves to June 14 without any manual update. That automatic recalculation is the core value of a wired Gantt chart dependency over a manually dated schedule.

A finish-to-start milestone works the same way. When the milestone diamond sits at the end of a phase, every task in the next phase chains off it. Move the milestone, and the entire downstream chain shifts with it.

When auditing your schedule, look for two warning signs: arrows that cross over unrelated task bars (a sign of out-of-sequence logic) and successor bars that start before their predecessor arrows arrive (a sign the dependency was set but the dates were manually overridden).

For a deeper look at how to show dependencies in a Gantt chart without creating visual noise, see how most teams get dependency display wrong before you finalize your layout.

Why finish-to-start dependencies improve your project schedule

Manually pinning dates to every task feels like control, but it works against you the moment any single task slips. Finish-to-start dependencies give your schedule a logic layer that adjusts automatically, so you spend less time firefighting and more time delivering.

Four outcomes make the case:

• Reduced rescheduling effort: When a predecessor task runs three days late, every downstream start date shifts with it. You update one bar on the Gantt; the rest follow. Without dependencies, you're manually touching a dozen tasks.

• Clearer team accountability: Each person knows their work can't start until the prior deliverable is done. That single constraint removes the ambiguity that causes teams to start tasks prematurely on incomplete inputs.

• Accurate finish dates: Tools that recalculate your project's finish date automatically can only do that when dependency logic, not hard-coded dates, drives the schedule. A finish-start with dates example makes this visible: change the predecessor's end date, and the project's critical path recalculates in seconds.

• Faster auditing: When you understand the four types of project dependencies, you can scan a Gantt and immediately spot where project schedule dependencies are missing or misaligned, before a deadline slips.

Good project dependency management starts with letting the schedule think for itself.

Common mistakes when setting finish-to-start dependencies

Three errors show up repeatedly when IT project managers configure a finish-to-start dependency in a real schedule.

Hard date locks that override dependency logic: This is the most damaging one. When you pin a successor task to a fixed "must start on" date, the tool ignores the predecessor task entirely. If the predecessor slips two days, your schedule shows no warning — the successor just starts late against a date that no longer reflects reality.

Skipping lag time: A finish-to-start dependency with zero lag assumes the next task starts the same day the previous one ends. That's rarely true. A 24-hour environment setup, a review cycle, a vendor handoff — all of these need explicit lag values, or your dates compress into an unworkable sequence. The four types of project dependencies each carry different lag implications worth understanding before you configure anything.

Chaining every task as finish-to-start by default: Over-linking creates a fragile schedule where one delay cascades through every downstream task. Map only the dependencies that reflect real work constraints, then build the full project timeline around your dependencies rather than around assumed dates.

Closing

A finish-to-start dependency is only as good as the dates anchoring it and the lag time you account for. The five-step process — identify the predecessor, confirm its finish date, set the dependency type, add lag, and validate the chain — takes minutes but saves weeks of manual rescheduling. Once you've set up your first finish-to-start dependency, move it into Taro, where every task relationship in your project can be mapped so that date changes on one task ripple through your entire schedule automatically. No more hunting for which tasks slipped or recalculating by hand.

FAQ