Every project takes 20–30% longer than planned. Every quarter has at least two or three initiatives that don’t hit their target dates. It’s the norm.
The norm is wrong. And the reasons behind it are not what most organisations think.
It’s Not Laziness or Incompetence
The most common explanation for missed deadlines is execution failure — the team didn’t work hard enough, manage their time well enough, or communicate well enough. This is almost always wrong.
Teams that consistently miss deadlines are usually working extremely hard. The problem is structural: they’ve been given more to do than is achievable in the available time, with insufficient resources, against requirements that kept changing.
Root Cause 1: Overcommitment at the Planning Stage
Most deadline slippage begins at the planning table, not in execution. Teams accept commitments that are optimistic, agree to scope that’s underspecified, and sign off on timelines that assume everything will go perfectly. None of those assumptions survive first contact with reality.
The fix is not faster execution. It’s more honest planning — which requires leadership to create the psychological safety for teams to say “this won’t fit” without being seen as resistant or underperforming.
Root Cause 2: Unplanned Work
Every team absorbs unplanned work throughout the quarter — production bugs, ad hoc requests, support escalations, unexpected dependencies. If the plan was built assuming 100% of capacity for planned work, unplanned work causes slippage. Always.
The fix is planning for unplanned work — explicitly holding a buffer (typically 15–25% of capacity) for work that will arrive but can’t be predicted.
Root Cause 3: Dependencies Without Owners
Projects slip when they’re waiting on something — a decision, a design asset, a data feed, an external vendor. When the dependency doesn’t have a clear owner and a clear resolution date, it sits blocking indefinitely.
Dependency management is one of the most underinvested areas in project management. Every dependency should have an owner, a deadline, and an escalation path.
Root Cause 4: Scope That Moves After Commitment
Scope changes after a commitment has been made are the silent killer of project timelines. The change seems small — “we just want to add this one feature” — but each small change erodes the buffer that was barely sufficient to begin with.
Scope changes should be treated as budget amendments: formally evaluated, explicitly approved, and accompanied by a timeline impact assessment.
