Why Good Teams Miss Obvious Deadlines: A Timeline Breakdown

This is one of the more useful teardowns I do with teams, because the answer is almost never 'the team wasn't good enough.' A skilled team with a reasonable deadline missed it by three weeks, and when we traced back exactly why, none of the causes showed up on the original project plan.

The estimate itself was fair, built by the people doing the work, not imposed from above. The first crack appeared in week two: a single senior engineer, whose availability the plan assumed, was pulled onto a production incident for four days. Nobody re-planned around the gap; the team just quietly absorbed it and hoped to make up the time later.

The second crack: a dependency on another team's API that was 'basically ready' turned out to need two more weeks of work neither team had visibility into, because the dependency was tracked as a single line item instead of its own mini-timeline with its own risk.

The third, and the one that surprised the team most in the retro: three separate 'can you also just...' requests from adjacent stakeholders, none coordinated with each other, each individually reasonable, collectively consuming almost a full week of focus.

None of these three things would have shown up if you'd only looked at the original Gantt chart. They show up if you ask, at every weekly check-in, three specific questions: is anyone on this team unexpectedly unavailable this week, is every external dependency still on track and not just 'probably fine,' and has anything been added to this team's plate since the estimate was made?

Deadlines aren't usually missed because of one dramatic failure. They're missed in small, unrecorded erosions that nobody adds up until the date arrives. The fix isn't a better estimate, it's a standing habit of surfacing erosion weekly, while there's still time to do something about it.