What are milestones and dependencies?

1. What is a milestone?

A milestone is a marker for a single important moment in a project. Unlike a task, it has no duration - it is a point, not a bar. In a Gantt chart it usually appears as a diamond or a flag sitting on one date, marking something like a kickoff, a design approval, a phase completion, or the final delivery.

Milestones exist to make the shape of a project readable at a glance. A plan might have 60 tasks, but only five or six moments that everyone actually cares about. Marking those moments gives the team and any stakeholders a set of landmarks: we are here, the next big checkpoint is there. That is why milestones are so useful in updates and client-facing views, where the detail matters less than the key dates.

A good rule is that a milestone should represent a decision or a handoff, not just the end of some work. "Design finished" is a weak milestone. "Design approved by client" is a strong one, because it marks a moment that unblocks the next phase and that people will plan around.

2. What is a dependency?

A dependency is a rule that links two tasks so that one controls the timing of the other. The most common form is finish-to-start: task B cannot begin until task A is done. In a Gantt chart, dependencies usually appear as arrows connecting the tasks, pointing from the one that must happen first to the one that waits on it.

Dependencies exist because most work is not independent. You cannot test a page before it is built, and you cannot build it before it is designed. Capturing those relationships is what turns a flat list of tasks into a schedule that knows its own logic. When one task moves, the tasks that depend on it move too, so the plan stays consistent instead of quietly going out of date.

There are four standard dependency types, though in practice finish-to-start covers the large majority of cases. The guide on Gantt chart dependencies breaks down all four and shows when the less common ones are worth using. For most projects, linking tasks in the order they genuinely have to happen is enough.

3. How do milestones and dependencies work together?

Milestones and dependencies work together because a milestone can sit at the end of a dependency chain, marking the moment a sequence of linked tasks completes. The dependencies drive the timing, and the milestone marks the checkpoint that timing leads to.

Take a website launch. The tasks - design, build, review - are linked by finish-to-start dependencies, so each one waits for the previous to finish. The launch itself is a milestone: a single dated marker that depends on the review task finishing. Because it is tied into the dependency chain, if the build slips by three days, the review shifts and the launch milestone moves with it. You get both things at once: the logic that keeps the plan honest, and the landmark that makes the key date visible.

This combination is also what makes delay tracking work. When a milestone is connected to its predecessors by dependencies, a slip upstream visibly pushes the milestone later, so a delay to a key date shows itself instead of hiding. The guide on tracking delays goes into how that cascade plays out in practice.

4. Milestones vs dependencies at a glance

They are often mentioned together, but they do different jobs. Here is a side-by-side view:

In short, a milestone tells you where the important moments are, and a dependency tells you why the tasks fall in the order they do. A milestone can have dependencies, but a dependency is never a milestone.

5. When should you use each?

Use milestones for the handful of moments people plan around, and use dependencies only where the order genuinely matters. Both are easy to overdo, and an overloaded chart is harder to read and slower to keep accurate.

Some practical guidance:

• Milestones: aim for a small number per project - kickoff, major approvals, phase completions, and delivery. If half your rows are milestones, they stop standing out and lose their point.
• Dependencies: link tasks only where a slip in one would directly cause a problem in another. If a dependency exists mainly for documentation rather than because missing it would break the schedule, it probably does not need to be there.
• Together: attach your key milestones to the tasks that actually unblock them, so a delay upstream moves the milestone. A milestone floating on a fixed date with no links will not warn you when it is at risk.

For a broader refresher on how these fit into the wider picture, the guide on what a Gantt chart is covers the basic parts, and Breeze has a useful write-up on how to set and track project milestones.

Common questions about milestones and dependencies

What is the difference between a milestone and a dependency?

A milestone is a single point in time that marks a key event, with no duration. A dependency is a rule that links two tasks and controls their order. A milestone can have dependencies, but a dependency is not a milestone.

Can a milestone have a dependency?

Yes, and it usually should. Linking a milestone to the task that unblocks it means the milestone moves automatically if that task is delayed, which is what makes a key date reliable rather than just a hopeful marker.

Do small projects need milestones and dependencies?

Small projects often need a couple of milestones for the key dates but few or no dependencies. If the work is mostly a short, ordered list, you may not need formal links at all - add them only where the sequence really matters.

How many milestones should a project have?

There is no fixed number, but a handful is usually right - the moments people genuinely plan around. Too many milestones dilute the ones that matter and make the chart harder to read.

Next steps

Start by marking the few moments that matter as milestones, then add dependencies only where one task truly has to follow another. Link your key milestones to the tasks that unblock them, and the plan will both read clearly and warn you when a key date is slipping.