Common Challenges 7 min read

Why Your Team Keeps Missing Deadlines

Slow decisions, unclear owners, fragile handoffs, and late disagreement compound optimistic estimates, and each one shows up weeks before the date.

By Asa Goldstein, QuestWorks

TL;DR

PMI found that only 55% of projects were completed on time. One cause is the planning fallacy: people underestimate their own work even when they plan for the worst. On tech teams, four team-level causes compound the estimation error. Decisions sit open for weeks, each deliverable has several half-owners, handoffs lose their safeguards as the date approaches, and doubts stay private until they can no longer be hidden. Adding people rarely helps, because coordination costs grow faster than headcount. Each of these causes produces visible signals weeks before the deadline slips: decisions reopened, owners nobody can name, basic questions at handoff, and meetings with no pushback. Managers who make those signals visible early can fix them while there is still time.

The sprint review is Friday. On Tuesday someone mentions, almost in passing, that the API contract changed two weeks ago. On Wednesday design and engineering discover they built against different versions of the spec. By Thursday you are negotiating which half of the feature ships. If your team keeps missing deadlines, this sequence probably feels familiar, and the usual diagnosis ("we estimated badly") explains only part of it.

You are in good company. PMI's 2021 survey found that only 55% of projects were completed on time. A McKinsey and Oxford study of more than 5,400 IT projects found that large ones ran 45% over budget and 7% over time, while delivering 56% less value than predicted. The schedule slip was modest compared with the value shortfall, which suggests many teams hit their dates by cutting what they ship. A team that lands on time with half the feature has still missed.

Estimation Error Is Part of the Story

The planning fallacy exists, and it is stubborn. Kahneman and Tversky named it in 1979, describing how people plan from the specifics of the task in front of them and ignore the track record of similar past work. In a later study, students predicted their thesis completion times far more optimistically than the actual times turned out, and even their "everything goes poorly" estimates came in short (Buehler, Griffin & Ross, 1994).

The same research contains a useful detail for managers: people underestimate their own completion times more than they underestimate other people's. Outside observers are less optimistic. So the first fix is cheap. Estimate against the history of similar work (what did the last three integrations take?), and bring in someone who is not doing the work.

Better estimates still leave the bigger problem untouched: how the team works once the plan meets friction. Four patterns recur.

Cause 1: Decisions That Take Too Long

Every open decision is a task nobody can finish. McKinsey's 2019 survey of 1,259 respondents found that managers spend 37% of their time making decisions, and more than half of that time is used ineffectively. Only 48% said their organization makes decisions quickly, and 68% of middle managers called most of their decision time inefficient.

Slow decisions also fail to buy better ones. In the same survey, respondents who reported fast decisions were 1.98 times as likely to report high-quality decisions too. (Self-reported data, so treat it as correlation.)

Jeff Bezos described the working rule in his 2016 shareholder letter: "Most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you're probably being slow."

On a small team, decision latency looks like a question parked until the next sync, or a design choice revisited in three meetings. The three-meeting decision diagnostic is a quick way to find where decisions stall, and how teams make decisions covers choosing a decision mode before the debate starts.

Cause 2: Nobody Owns the Outcome

Healthcare.gov is the textbook case. When the HHS Inspector General reviewed the 2013 launch, it found that CMS never named a single "business owner" with overall responsibility, and that the absence of clear leadership delayed decisions and left project tasks unclear.

Your team is probably eight people shipping a SaaS feature, and the pattern scales down anyway. When ownership is shared, a blocked task belongs to nobody until the week it is due.

Software research points the same direction. Cataldo, Herbsleb and Carley found that when developers' coordination matched the coordination their work dependencies required, developers resolved modification requests faster. Clear owners make that match happen: whoever owns checkout knows to talk to whoever owns payments.

A simple test: for each deliverable this sprint, can every team member name the one person who decides when it is done? If the answers differ, you have found the next slip.

Cause 3: Handoffs That Break Under Pressure

Every handoff is a place for context to leak. Herbsleb and Mockus studied a large software organization and found that work items spread across sites took about 2.5 times as long as similar items done in one location. The study measured distributed versus colocated work and did not track deadlines, but every cross-site work item carries at least one extra handoff.

Pressure makes handoffs worse. When a date gets close, teams skip the steps that protect the handoff: the review, the walkthrough, the readiness check. At Healthcare.gov, CMS pushed the marketplace readiness review from March to September 2013, weeks before launch, and launched without verifying that the system met its performance requirements.

The fix is to decide in advance which handoff steps survive a crunch. For many product teams the design-to-engineering transfer is the most fragile point, and why the design-engineering handoff breaks walks through the common failure points.

Cause 4: Disagreement That Surfaces Late

If someone doubted the approach in week one and said so in week six, the team paid for five weeks of work on a plan one of its members already distrusted.

Amy Edmondson's study of 51 work teams found that team psychological safety predicted learning behavior (speaking up, asking for help, discussing errors), and learning behavior in turn predicted performance. On teams without that safety, concerns stay private until they can no longer be hidden, which usually means close to the deadline.

The cost shows up in project data. PMI estimated in 2013 that for every $1 billion spent on projects, $75 million is at risk from ineffective communications. Bezos's "disagree and commit" from the same 2016 letter only works when the disagreement happens first.

Why Adding People Rarely Saves the Date

When a deadline slips, the reflex is to add hands. Fred Brooks put the counterargument in The Mythical Man-Month (1975): "Adding manpower to a late software project makes it later." New people need ramp-up time, some tasks cannot be split, and communication paths grow as n(n−1)/2. A team of 5 has 10 paths. A team of 10 has 45. A team of 20 has 190.

Brooks later called his own law an oversimplification, and adding people early to divisible work can help. The durable point is that coordination costs grow faster than headcount. If the underlying causes are slow decisions and unclear owners, more people multiply them.

The Signals Show Up Weeks Before the Deadline

A missed deadline is usually the last and loudest sign that a team struggles under pressure. The earlier signals are easy to miss: a decision reopened for the third time, a handoff where the receiving side asks basic questions, a standup where nobody pushes back on a plan that looks shaky, two people who each think the other owns the integration.

Most managers catch these by feel, which is unreliable while you are also shipping. Ways to make them visible:

  • Track decision age. List open decisions with the date each was raised. Anything older than a week gets an owner and a deadline.
  • Name one owner per deliverable. Write it in the ticket. Shared ownership is the default failure.
  • Protect two handoff steps. Pick the two checks that never get cut, even in crunch week.
  • Ask for the pre-mortem. At kickoff, ask each person how this project will slip. Write down the answers and revisit them at the midpoint.

Another option is to see how the team behaves under pressure before the pressure is on a deliverable. QuestWorks, a Team Intelligence platform, does this through a 25-minute weekly game day that works with Slack or Microsoft Teams: the whole team plays at the same time, seated into groups of 3 to 6, in cinematic, voice-controlled quests with time pressure and shared stakes. Participation is voluntary and never tied to performance reviews, and people at play behave authentically. Leaders get a weekly Team Intelligence Score (0 to 100) with an 8-week trend, named dimensions such as Decision Velocity, Role Clarity, and Launch Readiness, and a "Do this week" list of concrete actions. The tradeoff is time: it asks for 25 minutes a week from everyone, and a few weeks of play before the trend line means much. The plan is $199 per month per team (10 seats included) with a 30-day free trial (four game days), no credit card required.

Whatever you use, the goal is to learn that your team decides slowly or argues late in week two, while there is still time to change it.

Slow decisions and late disagreement usually trace back to trust, conflict, and commitment. Rate 15 statements to see which one is costing your team the most time.

Take the free team dysfunction assessment

Frequently Asked Questions

Estimation error is one cause, since people routinely underestimate their own completion times. Four team-level causes often compound it on tech teams: decisions that take too long, unclear ownership of deliverables, handoffs that break when the date gets close, and disagreement that surfaces late in the project.

The planning fallacy is the tendency to underestimate how long a task will take, even with experience of past slips. Kahneman and Tversky named it in 1979. In a 1994 study by Buehler, Griffin and Ross, students' predicted completion times for their theses were far more optimistic than their actual times, and even their worst-case estimates fell short.

Usually it does not. Brooks's law holds that adding people to a late software project makes it later, because new members need ramp-up time and communication paths grow as n(n-1)/2. Adding people early to work that splits cleanly can help.

Every open decision blocks the work that depends on it. McKinsey's 2019 survey found that managers spend 37% of their time on decisions and use more than half of that time ineffectively, and respondents who reported fast decisions were about twice as likely to report high-quality decisions as well.

Look for decisions reopened more than once, deliverables where team members name different owners, handoffs where the receiving side asks basic questions, and meetings where nobody pushes back on a shaky plan. These signals usually appear weeks before the date slips.

Teams that quest just work.

A game your team will love to play, and a weekly read on how they perform under pressure. 30-day free trial, four game days, no credit card.

Slack Microsoft Teams Try it free
Team Intelligence™, powered by play. Slack Microsoft Teams Try QuestWorks Free