A case study of a 60-engineer Series C company that missed a promised launch date by seven months despite every task estimate being accurate. The failure traced to a missing condition — a vendor identity provider contract that could not support regional deployment within the required timeframe — rather than bad estimation. The piece argues forward planning (listing tasks) misses conditions that others own, while working backwards from a specific outcome (goal regression, as in STRIPS planning and critical path method) surfaces these dependencies early when they are cheap to fix. Includes a cost breakdown showing $165K spent planning backwards versus $4.2M lost planning forwards, and draws on Flyvbjerg's project database, Boehm's cost-of-defect curve, and Kahneman's inside/outside view distinction.
Table of contents
Engineering Measures the Wrong ThingTasks Are Not ConditionsWhat Working Backwards Gives YouThe Cost of Finding Out LateWhy Teams Keep Planning ForwardsWhat This Is NotThe TestQuestions this post answers
Why do software projects miss deadlines even when every task estimate turns out to be correct?
Projects miss deadlines when the plan is missing a condition rather than because estimates were wrong. Estimation error is bounded and cancels out across many tasks, but a missing condition — such as a vendor contract requirement nobody flagged — only adds time and has no relation to the size of the plan. A 90-day vendor cycle dropped into a 24-week program causes a 54% overrun that no estimation method could catch. daily.dev surfaces engineering practices for teams tightening up how they plan and de-risk delivery.
What is the difference between forward planning and working backwards for a project roadmap?
Forward planning starts from today and lists tasks a team can do, which misses conditions the team doesn't own, like a vendor agreement or regulatory approval. Working backwards starts at the desired outcome and asks what else must be true for it to hold, surfacing both tasks and externally-owned conditions. The method traces to Fikes and Nilsson's 1971 STRIPS goal regression technique used in AI planning. Developers weighing planning methods can track approaches like this via daily.dev.
How much can finding a missing project dependency late actually cost a company?
In one documented case, discovering a blocking vendor contract requirement in month four instead of week one cost a company roughly $4.2 million in exposure, including $482,000 in rework, $2.1 million in delayed revenue, and $1.6 million from a lost contract, versus about $165,000 total if the same condition had been found during backward-planning in week one. daily.dev helps engineering leads keep tabs on planning practices that catch costly risks early.