Key takeaway
A dependency nobody wrote down is a risk nobody can manage, no matter how experienced the team is.
Every project of any real size depends on things outside its own task list: another team's deliverable, a vendor's timeline, an approval that sits with someone who is not in the daily standup. These cross-team dependencies are usually well understood by the people closest to them and almost invisible to everyone else, including, often, the PM, until the day one of them slips and takes a milestone down with it.
The frustrating part is that this is rarely a surprise to anyone who actually knew about the dependency. It is a surprise to everyone downstream who did not, because the dependency existed as tribal knowledge, mentioned once in a meeting six weeks ago, rather than as a tracked item anyone could check on.
Why dependencies are the risk category tools handle worst
A task list handles tasks well: what needs doing, who owns it, when it is due. It is much worse at handling the relationship between tasks, especially when the other side of that relationship sits in a different team's system entirely. Most tools were built to track what one team is doing, not what one team is waiting on from another, and that gap is exactly where cross-functional projects get quietly derailed.
Making the critical path visible before it breaks
The fix is not a heavier process, it is treating dependencies as first-class, trackable things instead of a mention in a status update. A dependency with an owner, an expected date, and a visible link to what it blocks can be checked on the same way a task can. It will not stop every delay, external timelines slip regardless of how well they are tracked, but it turns a silent, late-discovered failure into a visible, discussable risk with enough lead time to actually do something about it.