gantt
Dependencies get discussed as a planning topic and discovered as a scheduling emergency. The pattern repeats on teams of five to fifteen people. The plan looked reasonable in week one, a client review came back four days late in week six, and now three other pieces of work are late for reasons that have nothing to do with the people doing them. Nobody had written down that those three could not start until the review closed. The link existed anyway.
That is the entire subject, and it is smaller than the literature around it suggests. A dependency is not a feature in a tool and not a diagram. It is a fact about the work: one thing cannot proceed until another thing reaches a certain state. Writing it down buys one specific thing. When a date moves, the list of what else moves takes seconds to produce instead of a meeting.
A dependency is a relationship between two pieces of work in which the state of the first constrains the timing of the second. The task that has to reach a state is the predecessor. The task waiting on it is the successor. Everything else in the vocabulary is detail on top of that one sentence.
Four neighbouring terms get used as if they meant the same thing, and keeping them apart saves arguments later.
A constraint is a fixed point that no other task produces. A trade show on a set date, a contract end date, a regulatory deadline. Nothing upstream can be rescheduled to move it.
An assumption is something the plan treats as true without evidence. One round of review rather than three. Test data arriving usable. Assumptions turn into dependencies the moment somebody has to act to make them true.
A blocker is a dependency that has already failed. The predecessor has not delivered, the successor cannot start, and the date is now in question. Blockers are the visible form of dependencies that were never written down.
Float is the amount of time a task can slip before it pushes something else. Tasks with no float form the longest chain through the project, which is the critical path. On a small project the critical path is usually four or five items long and can be listed from memory once somebody actually asks.
The practical consequence of the definitions is a habit rather than a document. For each piece of work, the question is what has to be true before it can start, and who makes that true. If the answer names a person outside the team, the answer is a dependency worth recording.
Scheduling tools describe four relationships between a predecessor and a successor. Three of them appear in real plans and one almost never does.
| Link type | Reads as | Typical example | How often it earns its keep |
|---|---|---|---|
| Finish to start | B cannot start until A finishes | Copy approved before layout begins | Most links on most projects |
| Start to start | B cannot start until A has started | Testing begins once the first module is in staging | Useful for overlapping work |
| Finish to finish | B cannot finish until A finishes | Documentation cannot close until the feature closes | Useful at release time |
| Start to finish | B cannot finish until A starts | Old system stays live until the new one is running | Rare, mostly in cutovers |
Finish to start covers the large majority of links, and the risk with it is the opposite of under use. Chaining everything finish to start produces a plan where nothing overlaps and the total duration is the sum of every task, which no team works that way.
Start to start with a lag is the more accurate description of how work actually overlaps. Testing does not wait for all development to finish, it starts two days after development starts. That lag is a real number and it belongs in the plan rather than in somebody's head.
Lag and lead are where most schedules quietly go wrong. Lag is waiting time built into the link: concrete cures, a client needs three business days to review, a vendor ships in a week. Lead is the opposite, where the successor is allowed to start before the predecessor finishes. Teams frequently draw a clean finish to start link and then absorb the review time inside the task estimate, which hides it. When the review takes six days instead of three, the plan shows a task overrunning rather than a wait that was always outside the team's control.
The four link types describe shape. A second classification describes where the link comes from, and it matters more when a schedule has to be compressed.
Mandatory dependencies come from the nature of the work or from a contract. Foundations before framing. Security review before launch when the contract says so. These cannot be negotiated away by deciding to work differently.
Discretionary dependencies are choices, often made once by one person and never revisited. Doing all the wireframes before any visual design is a preference, not a law. When a date is under pressure, discretionary links are the only place real compression is available, which is why it is worth marking them as choices when they are made.
External dependencies sit with a client, a vendor, another team, or a regulator. The distinguishing feature is not difficulty, it is that no amount of effort inside the team changes the date. What can be managed is the ask date, the person who asks, and the agreed consequence if the answer does not arrive.
The fourth category rarely appears in the standard lists and causes as much damage as the other three combined. Two tasks have no logical relationship at all, but the same person does both. There is no arrow to draw between them and every scheduling tool will happily show them running in parallel. A resource dependency looks like a plan that works and behaves like a plan that does not, and the fix is a different person or a different week, never a different arrow. A board that shows people down one side and dates across the top makes the collision visible in a way a task list cannot, which is one reason the Features page treats the resource view as a view of the same cards rather than a separate report.
Dependency mapping sounds like a workshop. On a running project it is closer to an hour of transcription, and three passes find nearly everything.
Read backwards from each milestone. Take the date that matters, ask what must be complete for it to happen, then ask the same question of each of those items. Two or three levels back is enough. Going further produces a diagram nobody maintains.
Read the slips that have already happened. Every date that has moved so far was caused by something, and that something is a dependency with evidence attached. A date that moved because a dependency arrived late is worth recording twice: once as the link, once as the likelihood that the same link fails again.
Read the handoffs. Any point where work passes between two people, two teams, or two companies is a dependency whether or not it is drawn. The question that surfaces them is blunt: for this card, what arrives from somebody else, and what does somebody else get when it is done.
One filter keeps the output usable. Record a dependency only if the answer to it changes what somebody does this month. A project of fifteen people rarely needs more than fifteen to twenty recorded links. Past roughly thirty, the register stops being read and the important ones hide behind routine ones.
The recording method matters more than the notation, because a dependency written in a place people do not open is the same as a dependency nobody wrote down.
| Where it lives | What it does well | Where it fails |
|---|---|---|
| Arrows in a scheduling view | Shows the knock on effect of moving a bar | Needs one person to maintain the links |
| A date and an owner on the card itself | Sits next to the work, so it is seen while working | No automatic view of the whole chain |
| A separate dependency register | Good for reporting to a sponsor | Goes stale within weeks unless a meeting forces it |
| A chat message | Fast and honest at the moment of discovery | Unfindable two weeks later |
For a team of five to fifteen, the combination that survives is the second row plus a bar chart for the four or five links on the critical path. The dependency is written on the card as a needed-by date and a named person, because that is what the person doing the work reads. The chart carries only the handful of links where a slip moves a milestone.
The failure mode worth naming is the split system. The schedule lives in one tool, the tasks in another, and the conversation about the slip in a third. Nothing is wrong with any of them individually, and the dependency is still broken, because the moved date never reaches the two people who needed to know. Teams comparing tools on this specific point tend to be choosing between a rich scheduling model and one place that everybody actually opens, which is the trade off laid out across the comparisons.
Most of the pain of dependencies comes from the response rather than the discovery. Three decisions made in advance remove the weekly judgement call.
Decide who is told and how fast. A useful default is that the owner of the predecessor tells the owner of the successor the same day the date is known to be at risk, not when it is confirmed to have missed. A day of warning is often the difference between resequencing and idling.
Decide what happens by default. For each external dependency, write down now what the team does if the answer has not arrived by the ask date. Start on the next item, build against the assumption and accept rework, or stop and escalate. Writing the default down converts a two day discussion into a five minute one.
Decide the escalation trigger. Anything external that has not moved in two weeks goes to whoever owns the relationship. A fixed rule spares the delivery lead from deciding each time whether chasing is appropriate.
Then keep the response small. The instinct after a slip is to rebuild the plan, which costs a day and produces a plan the team stops trusting because it changes every week. Move the successor, look at whether the milestone moved, and tell the people affected. Rebuild the plan when the milestone actually moves, not when a task does.
Spend an hour listing the external dependencies on the current project, and for each one write the needed-by date, the person who will ask, and what the team does if the answer is late. That list is worth more than a full dependency diagram, because it is the part nobody can fix later. If the next change is getting the schedule, the tasks and the conversation about a slip into one place, Pinateca has a Gantt view over the same cards as the board and is free for up to five people and ten boards.
Around fifteen to twenty links for a project of five to fifteen people, and only the ones where a slip changes what somebody does this month. Past roughly thirty the register stops being read and the important links hide among routine ones. The test for keeping a link is whether anybody would act differently if it failed.
A dependency is the relationship, and a blocker is that relationship after it has failed. Predecessor late, successor unable to start, date now in question. Teams that only talk about blockers are describing dependencies they never wrote down, which is why the conversation always happens after the damage.
For the four or five links on the critical path, yes, because those are the ones where moving a bar has to show what else moves. For everything else, a needed-by date and a named owner on the card is read more often and maintained at lower cost. Drawing every link on a small project produces a diagram one person maintains and nobody opens.
Record three things: the date by which somebody will ask, the person who will ask, and what the team does if the answer does not arrive. The third item is the one usually missing and the one a sponsor is really asking about. A standing rule, such as escalating anything external that has not moved in two weeks, removes the need to decide each time.