Almost every professional has sat through the same uncomfortable moment: a deadline everyone agreed to, confidently, weeks earlier, is now clearly not going to be met. The instinctive explanations reach for individual blame \u2014 someone didn’t work hard enough, someone didn’t manage their time well. In most cases, that’s the wrong diagnosis. The much more common cause is a well-documented, near-universal planning mistake that has almost nothing to do with effort or discipline.<\/p>\n
Decades of research on how people estimate task duration have converged on a consistent finding: people are systematically, predictably overoptimistic about how long things will take \u2014 even when they have direct past experience showing that similar tasks took longer than planned. Ask someone how long a task will take, and they tend to answer with the best-case scenario, quietly assuming that this time, nothing will go wrong.<\/p>\n
The reason this happens so consistently is that when people estimate, they naturally focus on the specific plan in front of them \u2014 the steps as they’re supposed to unfold \u2014 rather than on the base rate of how similar tasks have actually gone in the past, across many attempts, including their own. A step-by-step mental walkthrough of a plan almost never includes the unplanned interruption, the dependency that turns out to be more complicated than expected, or the sudden competing priority that eats a day nobody budgeted for.<\/p>\n
Estimates are built from the best case, not the likely case.<\/strong> Most planning starts from “if everything goes as expected, this will take X,” rather than “based on how similar work has actually gone, this typically takes X plus a meaningful buffer.”<\/p>\n Dependencies get underestimated.<\/strong> A task rarely happens in isolation \u2014 it depends on information, approval, or input from someone else, and that handoff is one of the most common places delay quietly accumulates, often invisibly, until it’s too late to absorb.<\/p>\n New information changes scope mid-task.<\/strong> Plans are made with the information available at the start. As work progresses, new information routinely surfaces that expands what “done” actually requires \u2014 and that expansion is rarely factored back into the original deadline.<\/p>\n Competing priorities eat into planned time.<\/strong> A deadline set in isolation assumes the person working toward it has protected, dedicated time. In practice, unplanned urgent requests routinely consume time that was implicitly assumed to be available.<\/p>\n Early slippage goes unreported.<\/strong> A day lost in week one of a four-week project feels recoverable and rarely gets flagged. Several small, unreported delays like that compound quietly, and by the time the cumulative effect becomes visible, there’s no longer enough runway left to absorb it gracefully.<\/p>\n Build estimates from actual history, not from the plan alone.<\/strong> Before committing to a deadline, ask how long similar tasks have actually taken in the past \u2014 not how long they were supposed to take, but how long they genuinely took, including the ones that ran over.<\/p>\n Add a deliberate buffer, and treat it as part of the real plan, not padding.<\/strong> A buffer built in from the start, explicitly, tends to survive contact with reality far better than an aggressive deadline followed by an apologetic renegotiation later.<\/p>\n Map dependencies explicitly, and flag the riskiest ones early.<\/strong> Identify, at the outset, which parts of the plan depend on someone or something outside your direct control, and check in on those specifically and early, rather than assuming they’ll simply happen on schedule.<\/p>\n Create a low-friction way to report early slippage.<\/strong> If falling a day behind in week one feels like something that needs to be hidden or apologised for, it won’t get reported until it’s compounded into something much harder to recover from. A culture that treats early, honest flagging of slippage as useful information \u2014 not a failure \u2014 catches problems while there’s still time to adjust.<\/p>\n Revisit the estimate when scope changes, rather than holding the original deadline by default.<\/strong> If new information genuinely expands what the work requires, the deadline built on the old scope no longer applies, and pretending otherwise sets everyone up for a difficult conversation later rather than a manageable one now.<\/p>\n A project lead commits to a four-week delivery based on a step-by-step plan that looks solid on paper. By the end of week one, a key input from another department is a few days late \u2014 not a crisis, easily absorbed, and not worth flagging. By week two, a similar small delay happens with a different dependency. Neither delay alone seemed worth raising.<\/p>\n By week three, the two minor, unreported delays have compounded into a genuine problem: there’s no longer enough runway to complete the remaining work in the time left. Had either delay been flagged when it happened \u2014 rather than absorbed quietly, on the assumption that time would be made up later \u2014 the project lead would have had two extra weeks to renegotiate the deadline calmly, adjust resourcing, or trim scope. Instead, the conversation happens in week three, under pressure, with far fewer good options available.<\/p>\n Treating a confident estimate as a reliable one.<\/strong> Confidence in an estimate and the accuracy of that estimate are only loosely related \u2014 a plan can feel completely solid and still be built from an unrealistically optimistic base case.<\/p>\n Not building in a buffer, then treating every delay as exceptional.<\/strong> Without an explicit buffer, every normal, expectable disruption gets treated as an unusual exception requiring justification, rather than as the expected variability any realistic plan should have accounted for.<\/p>\n Punishing early honesty about small delays.<\/strong> If flagging a minor slip early gets treated as a failure, people will rationally stop flagging it \u2014 right up until the cumulative delay is too large to hide.<\/p>\n Holding the original deadline after scope has genuinely changed.<\/strong> Refusing to revisit a deadline when the underlying work has expanded sets an unrealistic target that everyone quietly knows won’t be met, which erodes trust in future deadlines as well.<\/p>\n Deadlines don’t usually slip because people didn’t try hard enough. They slip because plans are built from optimistic best cases, dependencies are underestimated, and small early delays go unreported until they’ve compounded into something much harder to fix. Plan from history rather than hope, build in a real buffer, and make it genuinely safe to flag slippage early \u2014 and you’ll miss far fewer deadlines, and recover far more gracefully from the ones you do.<\/p>\n Why do experienced people still underestimate how long tasks will take?<\/strong> How large should a planning buffer be?<\/strong> How can I encourage my team to report delays earlier?<\/strong> Should a deadline change if the scope of the work changes?<\/strong> Is it better to set an aggressive deadline to create urgency, or a realistic one?<\/strong> How do I estimate a task I’ve genuinely never done before?<\/strong> Missed deadlines aren’t usually a motivation problem. They’re usually a planning problem \u2014 and a specific, well-documented one at that.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"default","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[19,13],"tags":[9,20,15,39],"class_list":["post-2015","post","type-post","status-publish","format-standard","hentry","category-management-skills","category-productivity","tag-leadership","tag-management-skills","tag-productivity","tag-project-planning"],"yoast_head":"\nHow to Plan More Realistically<\/h2>\n
A Practical Scenario<\/h2>\n
Common Mistakes<\/h2>\n
Action Steps<\/h2>\n
\n
Key Takeaways<\/h2>\n
\n
Conclusion<\/h2>\n
Frequently Asked Questions<\/h2>\n
\nBecause estimation tends to focus on the specific plan in front of them rather than on the historical base rate of how similar tasks have actually gone \u2014 a bias that persists even with substantial experience unless deliberately corrected for.<\/p>\n
\nThere’s no universal number \u2014 it depends on the task’s complexity and how many external dependencies it has \u2014 but the key principle is building it in explicitly from the start rather than treating overruns as exceptional each time they happen.<\/p>\n
\nTreat early reporting of slippage as useful information rather than a failure, and respond to it constructively and without blame \u2014 teams quickly learn whether honesty about delays is actually welcomed or quietly punished.<\/p>\n
\nGenerally yes \u2014 holding an original deadline after the underlying work has genuinely expanded sets an unrealistic target and tends to erode trust once it’s inevitably missed.<\/p>\n
\nAggressive deadlines can create short-term motivation but often produce chronic overruns and erode trust in future estimates. A realistic deadline with a genuine buffer tends to be more sustainable.<\/p>\n
\nLook for the closest historical comparison available, even an imperfect one, and build in a larger-than-usual buffer to account for the added uncertainty of unfamiliar work.<\/p>\n","protected":false},"excerpt":{"rendered":"