Comment by okaleniuk | Hacker News Reader

Comment by okaleniuk | Hacker News Reader

I stepped in as a project manager for my R&D group when the war started. I wasn't going to but we had nobody else at the moment so here I am. One of the perks of this arrangement is that I basically can do whatever I want. Worse case scenario - I'm back to my engineering job I wasn't going to leave to begin with.

So the first thing I did when I stepped in is I made estimations paid. As a business partner, you can request an estimation for a feature, but an estimation itself then becomes a project. Alternatively, you can just tell me your deadline and we'll manage things on our side to fit your date. Do you know how many times did we do the "estimation as a project"? Once. And their project got cancelled anyway so we didn't even have to do the actual work and nobody knows if our estimate was accurate.

I've heard many times that business needs estimations. As it turns out, it doesn't. In times of inherent unpredictability, the real priorities show. All that business needs is to be better than competitors. It needs to create marketable value. It needs ideas, it needs analysis, it needs expertise and hard work. Estimations don't help create value. They only create more work. As soon as you make this work visible, poof - nobody wants estimations anymore!

Yep. I've been through this cycle too. The phrase that helped me sell the idea was "estimation is design". You can't come to an estimate that has any relationship to reality without knowing what you're intending to build, and that's a design function, even if it's very high-level, coarse, and approximate. Just expecting that design to materialise from thin air is extremely unrealistic, so you have to go through some sort of intentional process to get there. Making that process cause an appropriate amount of pain does make it clear that none of it is free.

Estimations are more important in large orgs with competiting priorities. (Or when you're going to be billing a client and they want to know, in an external-facing team like that.)

If you have a straight list of priorities it's not going to change how hard the project is or anything; you'll discover some stuff earlier that will help you project when to expect it, probably, but the work needed is still the work needed.

But if you have one VP who wants to do A and one who wants to do B and the higher-ups want to know how much they'll both cost in order to decide which to do first... then yeah, you need an estimate, but you also ideally need to make it clear that those estimates are going to take time and are going to take resources away from other work.

> But if you have one VP who wants to do A and one who wants to do B and the higher-ups want to know how much they'll both cost in order to decide which to do first...

Assuming that all efforts bring about the same value and it's only the cost that is different is a huge (but very common) mistake.

It's the other way around. Any time you're comparing two options they're likely to cost approximately the same, but it's likely one is wildly more valuable than the other. That is the thing that needs to be estimated.

I haven't seen an assumption of the same value, and didn't say that assumption was necessary - the decision-maker wants those value estimates too. Same basic principal - if value is X vs 3X but effort is Y vs 10Y... that's good to know. "Likely to cost approximately the same" has been very atypical in my experience.

Hopefully that estimation is done even in the "straight line, not-parallel priorities, no cost estimation needed" scenario!

Under no circumstances do the software estimations for major competing projects in any way affect the political decision. Even if the teams themselves sweat blood on the estimations, the politicians will get their own people to do their own opinions and argue with those.

The decisions are all a compromise between peers horse trading budgets.

AFAIK, the only single purpose one can ever achieve with an estimation is to do ROI analysis and make a go/don't go decision about a project. Any other goal won't be achieved.

With that in mind, it's perfectly natural for projects that need an estimation to be cancelled. Even if the ROI is positive, it has opportunity costs against other ones with a case clear enough that nobody needs the data for a decision.

> ROI analysis and make a go/don't go decision about a project

And if the estimate is even remotely realistic, the decision will always be "no go". Even if it's actually something that's actually needed.

Do we work in the same business? Software almost always has incredible ROI.

There are two types of software projects, roughly:

* Speculative, with the hope that the ROI will be a multiple of the money put in. These are often in support of revenue-generation.

* Maintenance, where the goal is to keep the software useful for as low a cost possible, so they have a shoestring budget.

I love this, but you can't always use it. Sometimes management needs an estimate (even if a coarse one) to decide whether the project is worth doing or not. Sometimes you're doing fixed-price bids for a customer, and you'd better know how much to ask for in the bid. And so on.

But your main point is absolutely right. Estimates aren't free. They're a project, even if a small one.

How do people find "quick wins" (high value things that are low effort) without some kind of estimate?

As an engineer I feel it's pretty common that no one works on the quick wins because they are toiling away at some big new thing.

"Quick wins" sounds a lot like taking out a loan of technical debt.

Ok - the best idea i have heard for a long time :-)

Reply on news.ycombinator.com