The question is not whether issues will arise. They will.
The question is whether the project leader can identify, own, escalate and resolve them before they multiply.
A proper issue log should show the issue, owner, date opened, severity, dependency impact, next action and escalation status. Without this, issues become gossip. Everyone knows there is a problem, but nobody knows who is carrying it.
That is where leadership matters.
The project leader may have more authority, more context, more relationship capital or simply a wider view of the system. Their job is not to micromanage every task. Their job is to unblock the system.
In real execution, issues are not always technical. Many are relational. A vendor needs pressure. A client needs clarity. A team member needs authority. A department needs a decision. A senior person needs to intervene.
Ignoring this is wrong. Pretending every issue can be solved through a dashboard is also wrong. Execution is technical, but it is also human.
Why Plans Break in the Real World
Plans break because they assume stability where there is movement.
They hide dependencies.
They confuse activity with progress.
They ignore friction.
They assign tasks without creating ownership.
They add details without creating clarity.
They look complete but fail to show where the project is fragile.
This is exactly why the Yarra course describes a useful plan as a network of cause and effect, not a pile of tasks. It says dependencies are the hidden joints of the system, and one delay can move other tasks, force rework and create confusion about who is late.
