Dependencies

Most projects do not slip because the work was hard. They slip because something they were waiting on arrived late, and nobody noticed until it had. Dependencies make that waiting visible.

Three levels

Task dependencies

A task depends on another task, or on a whole phase, in the same project. Dated on both sides, so conflicts can be detected.

Project dependencies

One project blocks or relates to another. Use for cross-team hand-offs.

Program dependencies

The same, one level up, for initiatives that wait on each other.

The at-risk flag

Where both sides have dates, StatusLoop checks one thing: does the prerequisite finish after the dependent work is due to start? If so, the task gets a warning marker, and the project header shows how many tasks are affected, linking to the earliest one.

Same-day is fine — a prerequisite ending the morning your task begins is not a conflict. Only a genuine overlap is flagged.

Why nothing moves automatically

When a conflict is flagged, StatusLoop offers a one-click reschedule that shifts the task to start after its prerequisite, keeping the same duration. It does not do this for you.

That is a deliberate choice. A plan that rearranges itself overnight stops being something anyone trusts, and cascading date changes through a dependency graph produces exactly the kind of surprise that makes people stop maintaining plans at all. The flag tells you; you decide.

Dependencies outside StatusLoop

For anything we have no dates for — another team's system, a vendor, a regulatory approval — use the free-text dependency field on a task. It will never be flagged, because there is nothing to compare it against, but it is visible to anyone reading the plan and it survives into exports.

A known limit

Only a direct two-way loop is rejected when you create a dependency — A depending on B while B depends on A. A longer cycle through three or more tasks is not detected. Since nothing cascades automatically, a long cycle is harmless rather than dangerous, which is why this has not been closed.

Using them well

• •Record the dependencies that cross a team boundary. Those are the ones that surprise people.
• •Do not record every sequential step inside your own team's work — that is what task order is for.
• •When a flag appears, either reschedule or go and change the prerequisite. Leaving it flagged teaches readers to ignore the marker.