“Dependency Tracker Template: Columns, Example and Step-by-Step Guide”

What is a dependency tracker template?

A dependency tracker template is a reusable table structure for recording the relationships between tasks, plus the waiting time or overlap attached to each one. It answers three questions per row: what has to happen first, how long after that the next thing can start, and who is accountable for the handoff.

It is not a task list with extra columns, and it is not a Gantt chart. A Gantt chart draws relationships as arrows on a timeline, which is excellent for seeing the shape of a plan and poor for auditing it. A board hides dependencies completely, which is why boards feel fast and then surprise everyone in week six. The tracker is the flat, sortable, reviewable version: one relationship per row, so you can filter by owner, count how many handoffs a single person owes, and spot the rows where the lag was set once in March and never revisited.

Teams keep this in a spreadsheet for three reasons. It survives tool migrations, it can be printed for a steering committee, and it forces the planner to name a number instead of gesturing at a timeline. When a dependency tracker is done properly, the Gantt chart becomes a view of the tracker rather than a separate source of truth.

What columns does a dependency tracker need?

Nine columns cover the work. Four more are optional and earn their place on projects with external vendors, regulated approvals, or more than about forty handoffs.

The optional four are escalation contact, contractual reference, cost of delay, and last review date. Add them when a missed handoff has a financial or legal consequence, and skip them when the tracker is an internal coordination aid used by five people.

Which dependency types exist, and how do they change the maths?

Four types are defined in scheduling practice: finish-to-start, start-to-start, finish-to-finish, and start-to-finish. Roughly 80% of real rows are finish-to-start, which is why templates that only support FS look fine until a phased rollout appears.

Two practical notes. First, SS dependencies are the most abused: a planner writes “SS +0” to show two tasks running together, then discovers the successor needed the predecessor’s first output, not its first day. Second, never mix dependency types on the same pair of tasks. If two tasks genuinely need both a start constraint and a finish constraint, split one of them.

How do you calculate lead and lag without getting it wrong?

Five rules settle most errors before they reach the schedule.

1. Choose one calendar. Working days or calendar days, not both. A five-day lag written on a Friday means Wednesday on a working calendar and Wednesday on a calendar calendar for that week only, then the two drift apart across holidays.
2. Lag is a duration, not a date. “+5 working days” survives a schedule shift; “starts after the 14th” does not.
3. Lead is negative lag. A lead of two days is `lag = −2`, not a separate column.
4. Count inclusively. If a task finishes on day 6 and the lag is 2 working days, the successor starts on day 9, because days 7 and 8 are the wait.
5. Never leave lag blank. A blank cell means “unknown”, and unknown becomes zero in every tool that imports it.

Worked example 1 — finish-to-start with lag. Design runs from day 1 to day 6. A drawing review takes 2 working days before fabrication can begin. Fabrication ES = 6 + 2 + 1 = day 9. If the client can review the drawings while design is still finishing, and the last two design days do not change the drawings, that becomes a lead: ES = 6 − 2 + 1 = day 5. Same two tasks, four days of schedule, one sign.

Worked example 2 — start-to-start with lag. Build starts on day 10 and runs 15 days. Documentation can begin once the first module is assembled, so SS +3 puts documentation ES at 10 + 3 = day 13. If documentation also has a finish-to-finish constraint of +0 against build, its EF must be at least day 24 (10 + 15 − 1). The later of the two computed dates wins.

Worked example 3 — float. Path A runs 18 working days and Path B runs 14. Both end at the same milestone, so Path B has 18 − 14 = 4 days of total float. A vendor on Path B slips 3 days: the milestone does not move, and 1 day of float remains. If the same vendor slips 5 days, the milestone moves by 5 − 4 = 1 day. This is the calculation that turns a status meeting into a decision.

Worked example 4 — lag inflation. A 60-row tracker where 26 rows sit on the critical chain, each carrying a defensive “+1 day” lag, adds 26 working days — about 5.2 working weeks — to the promised date. At a loaded cost of $4,200 per project day, that is $109,200 of schedule nobody agreed to. Padding every row feels prudent and is one of the most expensive habits in planning.

What does a filled-in dependency tracker look like?

Below is a nine-row excerpt from a 14-week fit-out project, with the derived start dates calculated from a day-1 start. Everything except the calculated start column is typed by a human.

Read the float column first. D-01, D-02, D-03, D-04, and D-09 have zero float, which means they form the critical chain; a single day lost on any of them moves handover. D-05 carries six days of float, so the joinery factory can miss its slot by six days before anyone needs to call the client. The trigger column is what makes the weekly review efficient: you are not asking “how is joinery going”, you are asking “was the factory slot confirmed by day 24”, which is a yes-or-no question with a date attached.

How do you build the tracker in seven steps?

1. List deliverables, not activities. Fifteen deliverables with clear completion criteria beat ninety activities named “coordinate”. Completion criteria are what make a predecessor falsifiable.
2. Order by handoff, not by department. Departments produce tidy rows that hide cross-team waiting. Start from the output each team needs from someone else.
3. Assign a type and a lag, then write the reason in the evidence column. “FS +5 — fabricator needs five days to book a slot, confirmed in email 12 Mar” is auditable. “+5” alone is folklore.
4. Compute the dates with formulas, not by hand. Put `=EF+lag+1` in a cell so the plan recalculates when reality moves. Hand-typed dates rot within two weeks.
5. Mark the critical chain. Sort by float and highlight zero-float rows. That shortlist is the only part of the tracker a sponsor needs to see.
6. Give every row one owner. Not a team, not a function. One person who confirms the handoff and escalates when it will not happen.
7. Set the review rhythm. Ten minutes weekly, sorted by trigger date, with authority to re-baseline. A tracker reviewed monthly is a historical document.

How do you know which dependency can slip?

Total float is the answer, and it is two subtractions: `total float = late start − early start`, or equivalently `late finish − early finish`. Free float is narrower: the days a task can slip without moving its immediate successor.

A tracker where 70% of rows have more than ten days of float is not a well-buffered plan. It is usually a plan with invented lags, and the invented lags are hiding the real constraint somewhere the planner did not want to look.

Which dependencies break most often?

Six categories account for most missed handoffs, and each has an early warning that appears days before the date.

Notice that all six are coordination problems, not technical ones. The schedule rarely fails because the work was hard. It fails because two people each assumed the other had confirmed.

What mistakes make a dependency tracker useless?

• Tracking every task instead of every handoff. A 400-row tracker is abandoned by week three. Forty rows reviewed weekly beats four hundred rows updated never.
• Using lag as a buffer. Lag should represent a real waiting period: curing time, review time, shipping time. If it represents optimism, it belongs in a contingency line, not in 30 rows.
• Leaving the owner column with a team name. “Procurement” cannot be asked whether a handoff will land.
• Hiding dependencies in chat. A dependency agreed in a direct message is not in the plan, so it cannot be reviewed, and it will be discovered late.
• Never closing rows. An open row that finished three weeks ago makes float calculations wrong and erodes trust in the whole register.
• Rebaselining without a record. Change the date, keep the original, and note why. Otherwise the tracker becomes a document that is always right and never useful.

Is a tracker better than a Gantt chart?

It depends on what you are doing with it, and the honest answer is that they solve different problems.

The practical arrangement is a tracker as the source of truth and a Gantt as its picture. Teams that maintain only the picture lose the audit trail; teams that maintain only the register lose the ability to explain the plan to anyone outside the project.

How does Doitify handle dependencies?

Doitify is our product, so read this as disclosure. Tasks, sub-tasks, checklists, owners, and due dates sit in the same workspace as Gantt charts, timelines, boards, calendars, workload views, and work reports. Dependencies are set on the task itself, which means the register and the picture cannot drift apart: change a lag, and the timeline and the workload view move with it.

That removes the most common failure of the spreadsheet version, which is a tracker that was accurate in April and is decorative by June. It does not remove the discipline. Someone still has to name one owner per handoff, write a lag with a reason, and review the critical chain weekly. A tool can hold the arithmetic; it cannot hold the accountability.

Conclusion

A dependency tracker template earns its keep by doing one thing well: it turns handoffs into rows with a type, a lag, an owner, and a float value. That is enough to separate the five relationships that decide the end date from the thirty-five that only need a glance.

Build the register with deliverables, not activities. Write lags with reasons attached. Sort by float, review by trigger date, and close rows the week they finish. The schedule will still move, but it will move for reasons you can name, price, and explain.

If this post on dependency tracker template was helpful, you might also enjoy Free Change Request Template and Project Management Software for Cross-Functional Teams.