Easy when software is the totality of development. When there's hardware design, marketing, training, etc. happening in parallel, top management needs to know how long it will take. Sometimes, if you don't get the software out the door by an arbitrary date, the company is finished; estimate accordingly.
This is exactly why software estimating is bullshit.
If the software has to be out the door by a specific date or the company dies - you DON'T NEED AN ESTIMATE.
Are you going to cancel the project based on the estimate? Dead Company
If the project is really too big to complete in time: Dead company, and optimistic estimates won't help.
If you could build a subset of the project and survive, then you still don't need an estimate - you just do the important stuff first.
If you were being chased by a lion, would an estimate of the time necessary to outrun it be of any use whatsoever? Of course not. You start running, and you either make it or you don't.
If there is other stuff happening in parallel, like marketing, then it is happening in parallel, and has no dependency on the software. That's what parallel means.
If you have a critical path dependency, then you're back to the situation above where you are going to make it or not, and the estimate won't really affect your ability to deliver.
Even estimating for cost is bullshit - if you practice lean development, you watch your metrics and if something doesn't work, just scrap it for the minimum amount of money lost. You can't do much better than that, except for not starting, and in that case you don't need an estimate.
I prefer the approach that saya "we're going to deliver feature X, and if it takes longer than Y or costs more than Z, we abort." You know exactly how much you stand to lose under this plan. The problem is, this means that management has to be involved on a day-to-day level with monitoring progress and making go/no-go decisions, when most managers I've met would prefer to have a single 3 hour planning meeting and then disappear for 4 months to raise money or play golf or go to tradeshows in Vegas or whatever.
No, correct estimations mean management knows "X cannot be done in time T", and now can act accordingly to decide what subset/variant of X to pursue instead.
I was responding to the comment that established "X must be done in time T" or the company fails.
In a perfect world, estimates would come before deciding to proceed, but in 95% of the places I've ever worked, the project necessity is decided first and the estimates are asked for afterwards.
In reality, the project often settles for a shoddy subset of the original vision in order to make an arbitrary date, when they could have had the same exact subset at much higher quality if they had merely proceeded with the important parts first in a lean/agile manner, using micro-estimates (if bothering to estimate at all).
A bigger problem with estimating the solution of unknown problems is that confidence in the estimate varies inversely with the precision (or usefulness) of the estimate. I could estimate all my projects with 99% confidence as "somewhere between 1 day and 1 year".
That's not a useful estimate.
Or I could estimate "this will take 42 days" and be wrong 99% of the time.
New feature is being developed. When ready, a marketing campaign will be launched to bring in the customers. This is done through tv-spots - which must be booked months in advance. Booking them before the feature is done would be disastrous. Waiting until it is done, before booking would mean months of lost opportunity.
This is less of a estimating issue and more of a "our startup only has 6 months of runway so don't fuck up" situation. Again, prioritization is far more important.
