A dependency tells Project Overview that one piece of work cannot happen until another has. Once it is set, the plan carries that logic with it: move the first piece and the second follows, instead of you having to remember the connection.
Setting one up
Right-click a project or a milestone and choose Manage dependencies. The dialog shows what this piece of work is waiting for, with an empty row at the bottom for adding another. Fill that row in and a fresh one appears, so you can add several without reopening the dialog.
A dependency is always managed from the side that is waiting. If Project B cannot start until Project A finishes, you set it up from B. Opening A's dialog will not show it, because from A's point of view nothing is being waited for.
The four kinds
Which one you want depends on whether it is the start or the finish of each piece that matters:
-
Finish to Start: B can only start once A is finished. Wall cladding cannot start before the building frame is done. This is the one you will use most, and it is what you get by default.
-
Start to Start: B can only start once A has started. Window installation cannot begin before wall cladding is under way, but the two then run alongside each other.
-
Finish to Finish: B can only finish once A is finished. The final inspection cannot be signed off before the cladding is complete.
-
Start to Finish: B can only finish once A has started. Removing the old cladding cannot be finished until fitting the new has begun. Rare, but occasionally exactly what you need.
Waiting time and overlap
Each dependency can carry a number of calendar days, and the sign is what matters.
A positive number waits
Insulation finishes on 10 March. Finish to Start with +3 means cladding starts no earlier than 13 March, giving three days for it to dry before anyone works on it.
A negative number overlaps
Wall preparation finishes on 10 March. Finish to Start with −3 lets cladding begin as early as 7 March, so the two trades work over each other for a few days.
What is and is not allowed
Project Overview will not let you build a plan that cannot exist. If you try, it says why rather than failing quietly:
-
A piece of work cannot depend on itself.
-
Dependencies join projects to projects, or milestones to milestones, not a project to a milestone.
-
Two milestones must belong to the same project. To connect work across two projects, put the dependency between the projects themselves.
-
Tasks cannot take part. Dependencies work at project and milestone level.
-
Circles are blocked. If A waits for B and B waits for C, then C cannot be made to wait for A. That would be a plan with no possible starting point, so it is refused at the moment you create it rather than discovered later.
What happens when you save
Saving a dependency applies it there and then. If the waiting piece of work currently starts too early to satisfy the rule, it is pushed forward far enough to be legal, keeping its own duration, and that shift carries on into its own milestones and tasks. If the dates already satisfy the rule, nothing moves at all.
This is not like dragging. There is no unsaved state and no Cancel. Saving a dependency writes the new dates immediately, which is worth knowing before you add one to a plan somebody is relying on.
Seeing them on the timeline
A dependency shows up as a small badge on the bar, with a line drawn between the two bars it joins. The bar that is waiting also becomes locked against dragging, which keeps your plan's logic intact. See Replanning with drag and drop.
Removing one
Delete a dependency and the badge and the line go with it, and the waiting bar can be dragged freely again. Dates already changed on the way in are not put back. Deleting the dependency lifts the constraint; it does not undo history.
Next: 7. Good to know