> What I find ironic is that everyone in the industry knows that estimating is very hard, thus estimations are nearly useless, yet everyone insists on the importance of planning and on basing such planning on void estimates.
Obviously, planning is critical. Planning means resource allocation. How is this not a critical aspect of any project?
The mistake you're making is presuming that if estimates are not crisp then they have no value.
> Nobody has yet had the balls to state the obvious: we have to learn to work without estimations.
This belief is detached from reality. Failing to provide estimates means a failure to scope how much work is required, which translates to not even knowing how many people should be working on a simple task.
The problem you're failing to address is limited information, and specifically limited context from developers and emerging requirements. Projects have been adjusting to this for decades. Agile developed concepts such as sprints and spikes for this very reason. It's not only about changes in requirements. It's mainly about gathering info and updating projects based on that.
Considering it very often fails even for successful projects, obviously, it is not.
> This belief is detached from reality. Failing to provide estimates means a failure to scope how much work is required
Your line of reasoning is detached from reality. The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are required, still they never get the right answer until the project is completed.
Development is what makes a project successful; planning is what makes a project late.
> Considering it very often fails even for successful projects, obviously, it is not.
This is not a relevant strawman (if it fails for some, it works for none?). Working without a plan isn't how humans work. You want to argue about scale, that's fine, but far from absolute.
> > This belief is detached from reality. Failing to provide estimates means a failure to scope how much work is required
> Your line of reasoning is detached from reality.
You provided nothing to indicate that the reasoning is detached from reality.
> The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are required, still they never get the right answer until the project is completed.
Any estimation I make for myself is not subject to it. My cofounders are not subject to some project leader who is trying to sabotage us. Simply put, this is another strawman to abdicate explaining the pros and cons (due to a lack opinion or thought?). It is not compelling.
> This is not a relevant strawman (if it fails for some, it works for none?). Working without a plan isn't how humans work. You want to argue about scale, that's fine, but far from absolute.
OP clearly fails to understand that the role of a project manager is to navigate ambiguity and uncertainty to deliver results in spite of them, and project managers are fully aware there is no such thing as crisp estimates and absolute certainties. Therefore OP puts strawmen regarding absurd notions of rigour that no one in the world adheres to.
I mean, hasn't OP noticed Project Manager's don't carry around stopwatches?
> The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are required, still they never get the right answer until the project is completed.
They don't know the true answer until the project is complete.
If my boss asks me how much time I need to integrate with some client system and I say I estimate one week, then if it's ready after four weeks that might be just fine for my boss.
My boss knows that there are factors that can affect the delivery of a project. What he almost always wants to know is are we talking days, weeks, months or years?
> Development is what makes a project successful; planning is what makes a project late.
So when you travel to new places, you just head in the compass direction? No looking at maps or similar?
> Considering it very often fails even for successful projects, obviously, it is not.
You are using a very personal and peculiar definition of failure, which is not shared by anyone else.
Back in the real world, companies hire project managers and put them in charge of projects without any concern or regret regarding the methodology. Do you think the whole world is wrong and you're the only one getting it right?
> Your line of reasoning is detached from reality.
Please explain exactly why you think scoping efforts have no relation with estimates.
> The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are required,
Yes, it's their job. What exactly do you struggle to understand?
> still they never get the right answer until the project is completed.
Yes, what about it? Exactly what do you have trouble understanding?
Experienced people develop different things than inexperienced people. Planning could simply involving experienced people to ensure the right thing is being built.
Obviously, planning is critical. Planning means resource allocation. How is this not a critical aspect of any project?
The mistake you're making is presuming that if estimates are not crisp then they have no value.
> Nobody has yet had the balls to state the obvious: we have to learn to work without estimations.
This belief is detached from reality. Failing to provide estimates means a failure to scope how much work is required, which translates to not even knowing how many people should be working on a simple task.
The problem you're failing to address is limited information, and specifically limited context from developers and emerging requirements. Projects have been adjusting to this for decades. Agile developed concepts such as sprints and spikes for this very reason. It's not only about changes in requirements. It's mainly about gathering info and updating projects based on that.