TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why overplanning makes projects fail?

43 点作者 spikey_sanju5 个月前

12 条评论

steveBK1235 个月前
Serendipity is real and hugely important to innovation.<p>That said, I&#x27;ve worked exactly 0 jobs that had too much planning in 20 YOE. However I worked lots of jobs with over-measuring. Constant check-ins, syncs, status meetings, team wide weeklies, etc. Measuring every step we take before we take the next one, but no vision as to wear this journey is supposed to actually lead.<p>This presents its own danger, and Big Agile Industrial Complex is the current manifestation of this problem.<p>I think its a micro-optimization that creates a macro problem.<p>We did not get from the Wright Brothers to a Boeing 777 with lots of minute check-ins and week-long visions of micro deliverables along the way.<p>You DO get improvements applying that process to say- churning out the current plane on the factory floor in a 25% more efficient manner, step by step. Not a lot of planning for what 6 months looks like there.<p>So one needs to match the type of problem they are solving with the correct amount of vision &amp; planning.
评论 #42332648 未加载
评论 #42331973 未加载
评论 #42339300 未加载
评论 #42331873 未加载
csours5 个月前
Planning and Learning are toxic to each other -<p>As you learn, the scope of the plan must change.<p>As you plan, you reduce the scope of what you may learn.<p>Example: We are migrating legacy code to new hosting with a small change. The plan is straightforward and simple. As we progress through migration we learn about unsupported dependencies and bad code practices in the legacy code, so we have to replan.<p>Previous comment: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41183984">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41183984</a><p>--- Bottom line:<p>If you don&#x27;t address budget when you talk about planning, you are missing the biggest problem.
perrygeo5 个月前
I&#x27;ve noticed one obvious commonality to failed projects: the plans are made in a vacuum of information, before data is gathered. This leaves land mines everywhere in the execution path, leading to big risks and large error bars on estimates.<p>Instead of course correcting to any new data, failed projects tend to double down on the process. Even as more information comes to light, it gets systematically ignored in favor of &quot;sticking to the plan&quot;. This is the death of software.<p>Of course I&#x27;ve seen projects that have basically no plan at all beyond the 2 week sprint. It&#x27;s not the presence or absence of a plan that hurts, it&#x27;s about the quality of the plan. Duck tape and prayers don&#x27;t constitute a plan either.<p>We need a tight feedback loop between planning and experimentation. Otherwise planning goes off the rails with bad assumptions, and experiments can go off the rails chasing new technology for its own sake. A planning process without a data-gathering period and an iteration loop to refine the design isn&#x27;t software engineering!
评论 #42333875 未加载
评论 #42332692 未加载
jajko5 个月前
Strict detailed plans give illusion of more control. But unless given domain and technology is very familiar and whole team knows it very well, unforeseen stuff cascading everywhere will wreak havoc on it.<p>Have you seen a very detailed plan yet very flexible release date mixed together?
评论 #42331719 未加载
vouaobrasil5 个月前
When I worked full-time, the biggest demotivator was when my manager wanted to plan every aspect of a project. It took all the fun out of exploring. And now I work for myself, and I am much more productive than ever because I just let most projects go where the wind blows...
评论 #42331950 未加载
spikey_sanju5 个月前
Here are a couple of Reddit threads on accidental inventions. It’s wild how small, unexpected moments led to some of the biggest discoveries ever. Uncertainty has its own kind of magic—it can spark the best ideas.<p>- What was invented by accident?<a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;AskReddit&#x2F;comments&#x2F;ygqwwl&#x2F;what_was_invented_by_accident&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;AskReddit&#x2F;comments&#x2F;ygqwwl&#x2F;what_was_...</a><p>- What is the best accidental invention?<a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;AskReddit&#x2F;comments&#x2F;1cajrnr&#x2F;what_is_the_best_accidental_invention&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;AskReddit&#x2F;comments&#x2F;1cajrnr&#x2F;what_is_...</a>
hermitcrab5 个月前
&gt;A scientist found mold in a petri dish that killed bacteria—and boom, we got penicillin.<p>Casually leaving out the vast effort of a whole team of people to develop the drug:<p><a href="https:&#x2F;&#x2F;www.sciencemuseum.org.uk&#x2F;objects-and-stories&#x2F;how-was-penicillin-developed" rel="nofollow">https:&#x2F;&#x2F;www.sciencemuseum.org.uk&#x2F;objects-and-stories&#x2F;how-was...</a><p>Fleming gets the credit, but Florey and a whole team of people of other people did the hard work.
评论 #42334085 未加载
slightwinder5 个月前
It&#x27;s basically the difference between top-down and bottom-up. For good planning, you need to have a good knowledge about your domain, and lay out all the routes and solutions, and then just execute them. But new greatness usually comes from the unexpored, dark corners of your knowledge-map, so it&#x27;s by definition kinda impossible to plan for greatness and success. Though, you can plan for raising the chances of finding success, but this is a different domain of planning, so it&#x27;s not something anyone can do just because they can plan other types of projects. And let&#x27;s not forget that humans are very depending on mindset and energy, to manage their limited mental abilities. Executing one type of plan will naturally prevent you from doing other things.
Nina10005 个月前
This is a great reminder of how unexpected success often comes from things we don’t plan for. Focusing too much on perfection can sometimes limit creativity, but you can’t just sit back and wait for things to happen either. It’s all about balance.
评论 #42332537 未加载
jiggawatts5 个月前
“It’s too hard to change the plan now.”<p>That one sentence alone is enough to explain the failures and I’m not even accounting for the very real cost overheads of planning.<p>Don’t try to change this! You can’t convince a PM that their job is not needed, their pay depends on it being a necessary function and they will fight dirty to protect that income no matter what.
评论 #42332715 未加载
评论 #42332658 未加载
spikey_sanju5 个月前
Why do some of our best ideas come out of nowhere? This post talks about how planning too much can kill creativity, and why greatness often shows up when you least expect it.
评论 #42331697 未加载
ElevenLathe5 个月前
Fake planning is the real evil. This is the kind where your entire quarter&#x2F;fiscal year is spoken for in an elaborate tree of initiatives&#x2F;milestones&#x2F;epics&#x2F;tasks painstakingly negotiated over months by your boss and many other parties without any input from you. First day of the quarter, you are invited to learn what inscrutable drivel is written in your tickets, and what totally random time estimates it has been given. Since this is immutable now and your performance review depends on being seen to have completed it, you start plotting ways to trick various people into explaining what they thought they were writing down. Of course you&#x27;re also &quot;doing agile&quot; so you have to pack all these tickets into &quot;sprints&quot; (a synonym for fortnights). Since all your work for the quarter is already known, this is a simple matter of deciding on day 1 the exact order you will work on it all for the next 3 months. Any deviation from this plan is considered unprofessional. You are doomed. You pour a cocktail, boot your workstation and log into your daily standup with the other prisoners. It&#x27;s a beautiful day but you&#x27;ll be inside playing with JIRA and arguing over the meaning of &quot;implement&quot; versus &quot;create&quot; with a &quot;technical PM&quot; that doesn&#x27;t know what Linux is.