I need that estimate and I need it now!

Throughout the years, I have been involved in more than my fair share of planning and estimation of software projects. To put it more precisely, planning to be able to estimate.

This is not about scrum planning or likes, this is more about estimating in grand, like 'plan and estimate that companywide pricing infrastructure'.

Here is a little quiz for you.

What is the purpose of estimation in software context?

a. big stick to flock development teams when the estimate over runs
b. box ticking exercise to create illusion of success
c. job creation schema for middle management
d. a tool to help make decisions.

If the answer is not loitering around d, estimation process starts to become actively damaging.

For a start, estimation requires some (or a lot) up front design, which is bad if not wrong for most of the time, which gets documented, sent to places that are not easy to retract.
Trying to come with estimations on imaginary solutions, writing all that is a real soul crunch, etc.

I think you should always come back to the naive question, why?
Why are we trying to estimate? And loop back to why until you arrive to a "real" decision point, by passing intermediaries like, 'I need those tasks' or 'we need a time line' or 'the management asks for this really'.

Is there a real alternative? Is it possible not to implement this? Are there alternative solutions? Or can you go ahead and buy a similar thing?

People are often a better bet than processes. Everyone wants to do a good job and take pride in it. Put together a good team, get them to work close without distractions and let them get on with it!