Gantt Chart Predecessors Explained: Types, Links & Examples

A Gantt chart can show every task and date while still leaving one crucial question unanswered: what must happen before work can begin? When predecessor links are missing or unclear, teams start tasks too early, overlook handoffs, and revise schedules after delays appear.

That confusion can spread quickly. A late approval may hold up several tasks, while an incorrect link can make a project look more flexible or more blocked than it really is. The good news is that predecessor relationships are straightforward once you know how to read the links. Here, I’ll explain the main link types, walk through practical examples, and show you how to build clearer dependencies into your schedule.

What Are Predecessors in a Gantt Chart?

A predecessor in a Gantt chart is a task that must reach a specified point before another task can reach its specified point. The task that depends on it is called the successor.

For example, a team must approve a page design before developers can build that page. Design approval is the predecessor; development is the successor. A line or link between their bars represents that relationship.

Predecessors explain the sequence of work, while task dates show when work is planned. Together, they help you see why a task starts when it does and which work may shift if an earlier task is delayed.

How to Read a Predecessor Link

Imagine a schedule with three tasks: draft a campaign, approve the copy, and publish the campaign. If approval cannot begin until drafting is complete, drafting is the predecessor of approval.

If publishing depends on approval, approval is its predecessor. The chain makes the order visible: drafting leads to approval, which leads to publishing.

• Predecessor: the earlier task or milestone that creates a dependency.
• Successor: the later task or milestone whose timing depends on that relationship.
• Dependency: the rule connecting two tasks, including how their start or finish points relate.

Why Predecessors Matter

A task list can show what needs doing, but it may not show what is blocking progress. Predecessor links reveal those connections and help you spot the effect of a schedule change.

For instance, if a permit approval slips by three days, a linked construction task may also move. Without the relationship, the schedule may still display the original start date, creating a misleading picture of the plan.

The Four Main Types of Gantt Chart Links

Most project schedules use four dependency types. Each type describes whether the predecessor’s start or finish controls the successor’s start or finish.

Here's why: choosing the right relationship makes a schedule more realistic. A team can start some work after another task begins, while other work must wait until that task is completely finished.

Finish-to-Start: The Most Familiar Link

With a finish-to-start relationship, the successor cannot start until the predecessor finishes. This is the usual choice when one task produces something another task needs.

For example, a team completes a product test before beginning release approval. If testing runs late, approval may need to move as well.

Start-to-Start: Work Can Overlap

A start-to-start link means the successor can begin after the predecessor starts. It does not mean both tasks must start at the exact same time.

For example, a communications lead might start drafting announcements once a product launch plan is underway. The plan can still be in progress while the announcement draft takes shape.

Finish-to-Finish: Completion Is Connected

A finish-to-finish link connects the finishing points of two tasks. The successor may begin earlier, but it cannot finish before the predecessor finishes.

For example, a team might begin assembling a final presentation while analysis is still underway. The presentation cannot be completed until the analysis is finished.

Start-to-Finish: A Less Common Handover

A start-to-finish relationship means the predecessor must start before the successor can finish. It is uncommon in ordinary project plans, but it can describe coverage handovers.

For example, an outgoing support shift may continue until the incoming shift begins. The new shift’s start permits the old shift’s final handover to finish.

How to Add Predecessors to a Gantt Chart

Start by identifying the work that truly depends on another task. Then connect those tasks using the relationship that reflects how the work will happen.

The best part? You do not need to link every task. Add a predecessor when a real handoff, required result, or timing condition affects the next task.

1. Break the project into manageable tasks. Use specific actions such as “approve homepage layout” rather than broad labels such as “website work.”
2. Identify dependencies. Ask what must happen before each task can start or finish. Note approvals, materials, decisions, and handovers.
3. Choose the link type. Use finish-to-start when work must be completed first. Choose another type when the work can overlap or only its completion point is linked.
4. Enter the relationship in the chart. Depending on your software, you may connect bars directly or select a predecessor from a task field.
5. Check the resulting dates. Confirm that the chart schedules each task in a way your team can actually follow.
6. Review the links when the plan changes. If a task, handoff, or approval requirement changes, update the relationship rather than adjusting dates alone.

Example: Planning a Small Website Launch

Suppose your team is launching a five-page website. The work includes approving page designs, building the pages, reviewing copy, testing the site, and publishing it.

Page development can use a finish-to-start link after design approval. Copy review might begin as soon as the first page draft is ready, creating a possible start-to-start relationship with development.

Testing may depend on the relevant pages being built. Publishing then follows testing and final approval. These links explain the sequence more clearly than dates alone.

Lead Time, Lag Time, and Overlapping Work

A basic dependency says how two tasks relate. Lead and lag time add a timing adjustment to that relationship.

Lag adds a waiting period between linked tasks. Lead allows a successor to overlap with its predecessor before the predecessor finishes, where the schedule permits it.

Using Lag Time

Suppose a concrete foundation must cure for two days before a crew installs equipment. The installation task depends on the foundation, with a two-day lag after the predecessor finishes.

That wait is part of the schedule, even though the crew may not be performing another task during it. Showing the lag helps avoid an unrealistic installation date.

Using Lead Time

Imagine a team painting a long hallway in sections. The next section might be ready to paint before the previous section is fully finished.

A lead can represent that allowed overlap in a finish-to-start relationship. Use it only when the work can genuinely overlap; otherwise, the chart may schedule a successor before its requirements are met.

Keep Timing Adjustments Explainable

When you add lead or lag, record the reason in a task note or planning convention. A short explanation, such as “two-day curing period,” helps teammates understand the timing.

Review these adjustments whenever estimates change. A previously reasonable overlap may become unsafe or impractical after the work scope shifts.

How Predecessor Links Affect the Critical Path

The critical path is the longest connected sequence of dependent tasks that determines the earliest possible project finish. A delay on that path can delay the whole project.

For example, if testing, approval, and release are linked in sequence, each may affect the launch date. A separate design task with spare time might move without changing the final milestone.

Use Links to Find Schedule Risk

Review the chains leading to important milestones. Ask which task delays would push a delivery date and which tasks have room to move.

A dependency map can also uncover a single approval that blocks several teams. That approval deserves attention because multiple workstreams may be waiting on it.

Do Not Link Tasks Just to Create a Chain

Every relationship should represent a real constraint. If two tasks are merely planned for the same week, that alone does not make one a predecessor of the other.

Unnecessary links can create artificial delays. They can also make normal changes appear to affect the project finish when the work is actually independent.

Common Predecessor Mistakes and How to Avoid Them

Predecessor links improve a schedule when they reflect real work. Incorrect or outdated relationships can obscure risk and make the plan harder to maintain.

Let me explain: many scheduling problems come from confusing task order with task dependency. A sensible review can separate the two.

• Linking every task in a simple sequence: Add a dependency only when one task’s timing genuinely relies on another.
• Using finish-to-start for every relationship: Check whether tasks can overlap or whether only their completion points need to align.
• Leaving out approvals or handovers: Include required decisions, access, and sign-offs when they control the next task.
• Changing dates without checking dependencies: Review connected tasks after a schedule adjustment to avoid conflicting dates.
• Keeping links after the plan changes: Revisit dependencies when scope, responsibilities, or work methods change.

For example, a team may first plan to complete all research before writing. Later, it may decide to draft sections as research becomes available. The original links should change to match the updated workflow.

Managing Project Work with ONES.com

When predecessor planning is part of a larger project, teams also need a clear way to manage work, workflows, reporting, and shared knowledge. ONES.com brings project management and knowledge management together in one unified platform powered by ONES Assistant. ONES Project and ONES Wiki are sold separately.

ONES Project is a project management product and a Jira alternative. ONES Wiki is a knowledge management product and a Confluence alternative. Teams can use them to organize delivery processes and the information that supports those processes.

Core Capabilities

• Workflows that feel familiar: Pain: teams may need to move established processes into a new platform. Capability: ONES Project supports Jira-compatible workflows. Result: teams can preserve familiar ways of moving work forward.
• Built-in reporting: Pain: project leads may struggle to understand progress across ongoing work. Capability: reporting is built into the product. Result: teams can review project information without relying on a collection of added plugins.
• Custom workflows: Pain: a standard process may not match an approval-heavy project. Capability: teams can create custom workflows. Result: task movement can reflect the organization’s actual review and delivery steps.
• Custom fields: Pain: teams may need to track details specific to their work. Capability: custom fields provide a way to capture those details. Result: project information can fit different team processes.
• Sprint management: Pain: agile teams need to organize work into time-boxed iterations. Capability: ONES Project includes sprint management. Result: teams can plan and follow sprint work within their project environment.
• Automation: Pain: repeated manual actions can add overhead. Capability: automation supports recurring project processes. Result: teams can reduce routine effort where automated rules fit.
• Reduced plugin dependence: Pain: several separate add-ons can make project operations harder to manage. Capability: built-in reporting and core project features reduce the need for plugins. Result: teams can rely on more native functionality.
• Deployment choice: Pain: organizations have different hosting and security requirements. Capability: ONES.com offers Cloud, On-Premise, Private Cloud, and Air-gapped deployments, with full feature parity between cloud and self-hosted versions. Result: teams can choose an environment that fits their operational needs.

Application Scenarios

Software release coordination: A product team can manage sprint work, custom approval workflows, and reporting in ONES Project. Release steps and handoffs can be organized alongside the project work they affect.

Distributed teams with shared processes: A team can use ONES Project for project execution and ONES Wiki for related knowledge management. Since the products are sold separately, an organization can choose the combination that suits its needs.

Organizations with restricted environments: A team with specific hosting requirements can evaluate Cloud, On-Premise, Private Cloud, or Air-gapped deployment. ONES.com also offers a free plan for up to 30 seats.

Common Challenges with Gantt Chart Predecessors

Several Tasks Depend on One Approval

Problem: Work across multiple teams stalls while one person or group provides approval.

Solution: Make the approval task visible and connect the affected work to it. Confirm who owns the decision and when the team will review its status.

The Chart Shows Impossible Dates

Problem: A successor appears to start before its required predecessor has finished.

Solution: Check the link type, lead or lag adjustment, and task dates. Confirm that the intended overlap is possible in real work.

Teams Do Not Agree on the Relationship

Problem: One team expects a task to wait for complete sign-off, while another expects work to begin after an initial review.

Solution: Discuss the exact start or finish condition. Capture the decision in the task details so the schedule reflects a shared understanding.

Dependencies Become Outdated

Problem: A changed plan leaves old links in place, making the chart harder to trust.

Solution: Review affected links whenever scope, sequence, or ownership changes. Remove relationships that no longer represent an actual constraint.

FAQs About Gantt Chart Predecessors

What is the difference between a predecessor and a successor?

A predecessor is the task whose timing affects another task. The task affected by that relationship is the successor. For example, if a team must approve a design before building a page, design approval is the predecessor and page development is the successor. The relationship also specifies whether the successor’s start or finish depends on the predecessor’s start or finish.

Which predecessor link should I use most often?

Finish-to-start is common when a task must be complete before another can begin. Use it for relationships such as approving a design before building it. Other links can better represent overlap or connected completion points. Choose the relationship that matches how the work really happens, rather than selecting the same link automatically for every pair of tasks.

Can a task have more than one predecessor?

Yes. A task may depend on several earlier tasks. For instance, a product release could require completed testing and final approval. Add each genuine dependency, then check whether all of them are required before the successor can start or finish. Too many unnecessary links can create artificial schedule restrictions, so make sure each one reflects a real condition.

Can two tasks have the same start date and no predecessor link?

Yes. Tasks can happen at the same time without depending on each other. For example, a finance team may prepare a budget while a design team develops a concept. Their shared start date may reflect the overall plan, but it does not mean either task controls the other. Add a link only when one task’s timing depends on the other.

What happens when a predecessor is delayed?

The successor may need to move if its timing depends on the delayed task. The effect on the project finish depends on the link, available scheduling flexibility, and the task’s place in the critical path. Review connected work after a delay, then update dates and communicate any changes to the people responsible for affected tasks.

Conclusion

Predecessors show which tasks control the timing of other work. Once you understand the four link types, you can represent handoffs, overlap, waiting periods, and completion conditions more clearly.

When a schedule feels confusing, identify the real dependency first, choose the appropriate relationship, and check how a change affects connected tasks. That simple review can expose bottlenecks before they disrupt delivery and help your Gantt chart reflect the way the project will actually run.