Gantt Chart Basics: Using Dependencies

If you’re totally new to using Gantt charts, check out my post about the critical path method, which explains what Gantt charts are and how to use them in a meaningful way when scheduling your projects.

But if you already have a basic grasp of Gantt charts and just want a little help mapping your dependencies correctly, then you’re in the right place! Let’s roll up our sleeves and dig into the mechanics of connecting tasks on a project schedule.

What is a dependency?

A dependency is, basically, the relationship between two tasks on your project. All tasks on your project are related in a general sense because they’re a part of the same project and driving toward the same project outcomes. But a dependency exists when one task “needs something from” another task in order to proceed. Or, put another way, you need an output from one task to be an input to another task. The task that needs the input is directly “dependent on” the task providing the output.

For example, at my organization, we send a lot of mass emails. In order to do this, “Haley” writes the copy (the text) for the email, and “Sean” builds and schedules the email within our email software. Sean can’t build the email until he has the text from Haley—Haley’s text is the output that Sean’s task needs as an input. Therefore, Sean’s task is dependent on Haley’s.

In a very simple project, your schedule could be an ordered list of tasks with due dates where each task is dependent on the previous task, and work could proceed one task at a time through your schedule:

1. Determine target audience and recipients for email. (Due June 7)
2. Write copy for email. (Due June 14)
3. Build and schedule email. (Due June 21)

But most projects led by a project manager are more complex than this. Many tasks can be dependent on a single task, or one task might need outputs from many different tasks, and you’ll need a way to track which tasks actually need to wait on other tasks and which don’t in order to complete the overall project in the shortest possible time (which typically allows the project to add the most business value). This is the goal of the critical path method, and identifying and tracking dependencies makes it possible.

Predecessors and Successors

While working with dependencies, you’ll hear the terms "predecessor" and “successor,” or “predecessor task” and “successor task.”

When you’re talking about a specific dependency, the predecessor task needs to happen first, and the successor task is the one that must wait on its predecessor. The predecessor creates the output that the successor needs as an input.

Any one task in a project is not universally considered a predecessor or a successor, but when you’re talking about any one dependency between two tasks, you can use these terms to clarify which of the two tasks you’re talking about.

Drawing or Noting Dependencies

When tracking dependencies in a project—especially in project software—you’ll usually see dependences recorded in one (or both) of two ways.

Visually as an arrow

I most commonly think of a dependency as an arrow on a Gantt chart. This is a predecessor task and a successor task with an arrow between them representing the dependency:

These dependency arrows can also exist on a network diagram, which is basically a Gantt chart but without any actual dates. A network diagram simply notes how long each task should take and where dependencies exist.

Dependency notation

But there is also notation for dependencies that both humans and software can understand.  For a given task, you’ll note its predecessors, and you’ll do so like this:

The task number is the number of the task on your list, in your spreadsheet, or in your software.

The dependency type will always be two letters; I’ll explain your options in the next section.

Lead or lag is about whether the successor task starts earlier or later than the end of the predecessor task. Most dependencies do not include it, but it’s important in certain situations. I’ll explain how it works near the end of this post.

But for now, know that these are the 3 parts of dependency notation and what they refer to. Here are some more examples of what actual dependency notation might look like:

• 2FF
• 114FS
• 32SS - 2d
• 60FS + 20d
• 16FS

Types of Dependencies

When drawing or noting a dependency, you have 4 types of dependencies to choose from, and you choose the type based on whether you’re noting a relationship between the beginning or end of the predecessor and successor tasks. One type is most common, two are useful in special situations, and one will almost never have a practical use case.

Finish-to-Start (FS)

A finish-to-start dependency is the dependency in most of the examples in this post and is the most common type you’ll see or use. It means the predecessor task must finish before the successor task can start. You’ll draw your dependency from the end of your predecessor task to the beginning of your successor task, like this:

Example: You’d use a finish-to-start dependency to indicate that development on a software feature must be complete before you can hold a demonstration of that feature for the client.

Finish-to-Finish (FF)

A finish-to-finish dependency will be useful occasionally. It indicates “the predecessor task must be finished in order for the successor task to also finish.” You’ll draw your dependency from the end of your predecessor task to the end of your successor task, like this:

Example: At my company, our web developer might be working on a landing page for an event at the same time that another staff member builds the registration form for the same event. They can work in parallel and both be nearly finished at the same time, but there needs to be a link to the registration form on the landing page. The “Build the landing page” task needs the registration form link as an output from the “Build the registration form” task in order to cross the finish line on the landing page. So “Build the registration form” would be its predecessor in a finish-to-finish relationship.

Start-to-Start (SS)

A start-to-start dependency also has its place. It indicates “the predecessor task must be begin in order for the successor task to begin.” You’ll draw your dependency from the beginning of your predecessor task to the beginning of your successor task, like this:

Example: While this might not be on a typical Gantt chart, think about the opening procedures at a restaurant. The shift manager might be assigned to “Open restaurant” which would entail unlocking the door, turning on dining room lights, setting out certain items, ensuring cleaning was complete from the night before, etc. But the chef could be assigned to another task, “Preliminary food prep,” and he wouldn’t need to wait until the dining room was ready to begin his work in the kitchen—he just needs the shift manager to get started by unlocking the door so he can get in. Therefore, “Open restaurant” would be a predecessor to “Preliminary food prep” in a start-to-start relationship.

Start-to-Finish (SF)

A start-to-finish dependency is the one you’ll almost never use. It is, in a sense, a “backwards” dependency, saying that the start of a task that’s later on the timeline drives the end of a task that’s earlier on the timeline. If you ever have to use this, you’ll draw your dependency from the beginning of your predecessor task to the end of your successor task like this:

Example: Let’s say we have a project where a software developer had been developing a software program to automate updates to a database. The software was almost complete and ready to go live, but the developer had a family emergency and suddenly went on unplanned leave for 12 weeks. In her absence, it was determined that another team member would maintain the database manually for 12 weeks, and the software could go live when the software developer returned and could confirm everything was ready to go.

So we have a task called “Make manual updates to database” with a duration of 12 weeks, followed by a one-day task called “Make software live.”

But let’s say the software developer’s family emergency hasn’t concluded after 12 weeks, and her leave extends another 4 weeks. That means the beginning of the “Make software live” task gets moved to 4 weeks later, and consequently, the end of the “Make manual updates to database” task also gets moved to 4 weeks later, because the manual updates can’t end until the software implementation starts.

The software implementation happens after the manual database updates in sequence, but the start of software implementation—the start of the later task—is the thing driving the end of the earlier task. That’s why, in this very odd scenario, you’d dust off a start-to-finish dependency.

Lead and Lag

Once you’ve identified your dependency type, you may occasionally need to add lead or lag. The default when you denote any type of dependency is that the successor task can proceed immediately on the heels of the predecessor: for a finish-to-start, the successor can start immediately after the predecessor is finished; for a finish-to-finish, the successor can finish immediately once the predecessor is finished; etc.

But sometimes you need to add an offset to this relationship, where the successor task proceeds either earlier or later than “immediately after the predecessor.” If it starts earlier, that’s lead. If it starts later, that’s lag.

Lag

With lag, you’re adding extra days between your predecessor and successor where no work is happening on either task. You’ll typically use lag when you need to wait between tasks for some reason.

Example: Let’s say you have a finish-to-start relationship where your predecessor is “Paint house” and your successor is “Add boards to house for mounting new deck.” But after you finish painting the house and before begin mounting boards to it, you need to wait one day for the paint to dry. You’d add one day of lag, and it would look like this:

Lead

With lead, you’re saying that even though (for example with an FS dependency) the end time of the predecessor drives the start time of the successor, the successor can still start earlier than when the predecessor ends.

Example: Let’s say you have a finish-to-start relationship where your predecessor is “Write newspaper articles” and your successor is “Lay out newspaper.” For the most part, articles need to be written before layout can begin, but when writing is almost complete, the designer doing the layout can get a head start by duplicating her file from the last issue, updating the header with the correct date, adding a fresh accent color to all the pages to differentiate it from the last issue, etc. So “Lay out newspaper” would be dependent on “Write newspaper articles,” but with one day of lead, like this:

It’s important to remember with both lead and lag that that the dependency relationship is still the thing driving when the successor can start. This matters if your timeline changes. So if you have a finish-to-start dependency with 3 days of lead and the finish date of the predecessor moves 3 days later, the start date of the successor will also move 3 days later, even though it is still starting 3 days before the end of the predecessor in both the old and new timelines. Lead and lag can start to look a little weird with some of the different types of dependencies, but if you’ve correctly identified when the start or end of the predecessor is the thing driving the start or end of the successor, even if there’s an offset, then you’ve done it right.

This should be everything you need to get started with dependencies on your Gantt chart, network diagram, or project schedule. Any one project will have many of these dependencies and can become a complex web very quickly—but still one you can understand and follow with a bit of practice. And in my opinion, a Gantt chart with accurate dependencies is the quickest way to understand which tasks are ahead of or behind schedule, and where you as the project manager need to dig in or nudge to keep things moving.

Happy tracking!