How Project Dependencies Work

A project dependency is a link between two tasks that records how they relate. The link people mean in a schedule is a block: this task is in the way of that one. A second kind of link only says the tasks are related. It does not move a date.

If you remember that split, most dependency arguments get shorter. Teams get into trouble when every connection is treated as a schedule rule, or when the tool is asked to lag, baseline, and calculate a critical path it does not have.

Two kinds of link

Blocks. Task A blocks task B when B should not be treated as free to finish on its own schedule until A is out of the way. The homepage design blocks the homepage build. The signed brief blocks the design. On a Gantt-style chart, this is the arrow. It is the predecessor idea, stated in plain language: one task is in front of the other.

Related. Task A relates to task B when someone should see both, but neither one holds the other up. The launch email relates to the homepage build. They ship around the same time. Neither is a predecessor. A related link is context. It is not a promise that one date pushes the other.

Write the link in a sentence before you click it. “Design blocks build” is a block. “The email is about the same launch” is related. If you cannot finish the sentence, you do not have a dependency yet. You have two tasks in the same project.

What a blocking link does not do

A block is not a full scheduling engine. In many products, including Dayzen, a blocking link does not:

• Add lag (“start three days after the previous task ends”).
• Offer finish-to-start, start-to-start, finish-to-finish, and start-to-finish as four different rules.
• Reach across workspaces. Both tasks have to live in the same workspace.
• Create a milestone. A milestone, if you need the word, is just a task with a date and almost no duration. There is no separate milestone object to file it under.
• Calculate the critical path or the slack on every other task.

You can still plan. You put a start and a due date on each task, you mark the real blocks, and you read the sequence yourself. You do not get an automatic answer to “what is the longest chain?” unless a different product feature does that math. Do not document a process that depends on math the tool will not run.

A worked example

A team is preparing a one-day customer workshop.

Task	Depends on	Link type	Why
Agree the agenda	—	—	Starts the chain
Book the room	Agree the agenda	Blocks	The room follows a real agenda
Send the invite	Book the room	Blocks	The invite needs a place and a time
Draft the slides	Agree the agenda	Blocks	Slides follow the agenda
Print the name cards	Send the invite	Related	Useful together, not a schedule lock

Book the room blocks the invite. Drafting slides also blocks on the agenda, and it can run beside the room booking. Printing name cards relates to the invite because the names come from the guest list, but printing does not hold the invite, and the invite does not hold printing. Marking that pair as a block would pretend there is an order the team does not actually follow.

If the agenda slips two days, the tasks it blocks need new dates. The tool may show you the arrow. It may not push every downstream date for you. Check the dates after the slip. An arrow that nobody updates is worse than no arrow, because people trust it.

Where to look at dependencies

A list can show a “blocked by” note on the task. A board usually cannot. Cards in a column do not show order unless you open them. A Gantt chart is the view that makes blocks visible, because the bars and the arrows sit on a calendar.

Do not force every task into a chain so the chart looks complete. Unrelated work that happens to share a week is not a dependency. Extra arrows hide the few that matter.

Also keep dependencies inside one workspace. If two client projects live in different workspaces, you cannot link a task in one to a task in the other. That is a boundary, not a missing click. If the work truly blocks across that line, the tasks belong in the same workspace, or you track the handoff in writing instead of a link.

Common mistakes

The first mistake is a chain of blocks that only describes the order you hope for. “Write, then design, then build, then launch” looks tidy and ignores that design and a legal review can happen together. Extra blocks make a slip look larger than it is, because every downstream task appears trapped.

The second is using a related link and then telling the client it protects the date. Related does not hold a successor. If the date matters, the link has to be a block, and the dates still have to be edited when the predecessor moves.

The third is storing the real sequence in someone’s head because the tool felt fussy. A single block on the two tasks that actually gate the launch is more useful than a perfect diagram you never update. Start there. Add a link only when someone has already been surprised by hidden order.

How to add one without making a mess

1. Name the predecessor and the successor in a sentence.
2. Choose blocks only if the first task is in the way.
3. Choose related if people only need to see both.
4. Confirm both tasks are in the same workspace.
5. Put real start and due dates on the blocking pair if you expect to read them on a timeline.
6. After a date changes, look at the tasks it blocks and update those dates. Do not assume they moved.

Review the links when a project changes shape. A block that made sense in week one is often leftover structure in week six.

How this works in Dayzen

In the Dayzen Project Management System, a task relationship is either Blocks or Related to. Both tasks must belong to the same workspace. The Gantt view uses blocking links for its arrows. A related link does not act as a schedule rule on that chart.

There is no lag field, no set of four dependency types, and no milestone record separate from a task. There is no critical-path calculation. Use dates on the tasks plus blocking links, and update the downstream dates when a predecessor slips.