Nobody has yet had the balls to state the obvious: we have to learn to work without estimations.
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.
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.
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.
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?
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?
If you don't know if its 500 or 5000 hours - you're simply not buying the product.
I do note that construction projects are also not good at estimating, but it's folly to suggest that at some level we are not _manufacturing_ rather than _developing_ a widget.
Estimating large projects is a big construction projects. Those tend to be large buildings and relatively on schedule. Estimating small projects with small teams is bespoke. And more likely to go off schedule when the plumbers can't time well with the electrical services, i.e, you have a dependency on another teams API or something, similarly to how software struggles in small team open ended scope projects with unknowns. But a tightly scoped single-trade software project won't struggle just like construction.
In end, I agree with you that construction is a decent metaphor. But construction is very far from manufacturing a widget, as it's a bespoke manufacturing process with ample site specific constraints
Is it possible to estimate the duration of a process that has never before occurred (e.g. the construction of something novel) with any expectation of accuracy?
"After some indulging in alcoholic beverages, we have signed a contract for <vaguely specified features> to be shipped on <date out of someone's hat>: please, do your best!"
And the outcome would have been even better if we hadn't waisted so much time in preparing detailed estimations and later inventing a justification about why those estimations were not precisely met.
I think estimates are a problem where you have say 10 estimates, you add then up to 47 days, divide by 3 people, call it 16 days… ah about 3 weeks that’ll be done. That is dumb!
But as an order of magnitude it is useful.
> have to learn to work without estimations.
A closely related, but different time management tool is a budget. Consider the same website but made in: 3 hours, 3 weeks, or 3 years. The methodology and tradeoffs the engineer approaches each of those projects is very different and needs to be known up front.
Part of the goal of estimation should be to create a budget for various key areas of the project, not guess how long it will take to fix 5 critical system bugs.
That's all well and good in a world that's pure software (and that does happen in those environments). It's not realistic in a world with lead times on physical items that are at least 1 year. For example, if you want to set up a high volume manufacturing line for a new product that takes a lot of planning in advance. You need to spend 10s to 100s of millions of dollars on a contract and schedule with the manufacturer and you need to be able to have SOME indication of where in that process firmware might be released (or more realistically - given the timescale, what scope of software is possible).
Age old conundrum: "Who will bell the cat?"