[creer]

> Absolutely none of those can be measured

They can be estimated (with a wild range) and that's still useful: If that impact is clearly in the noise, drop it. If that impact is clearly huuuge then set up some ongoing measurements and get started step-wise and demonstrate results. If you think you need to rebuild the whole thing before seeing any results, you see the world in a way that won't happen (except if your business is not delivering solutions but is selling solutions - in which case carry on). That doesn't mean the ground idea is incorrect.

[awesome_dude]

Can you demonstrate, or show how that would work (serious question)

[creer]

Sure. Let's take that idea:

> reduce vectors for bugs (which are always based on misunderstandings)

Is that really impossible to measure? (For cheap that is. Cheap measure, cheap estimate, cheap confidence). Is that really impossible to monitor?

Grab a random sample of 100 fixed bugs in the past 2 years. Go through them one by one. How many do you really seriously think would have been avoided? If it's not much more work, give it some weighting on confidence and impact or something. For how much addl work? Once you notice what you could count, restart from the top (re-randomize?) - it's only 100 bugs. Is it really 100%, or is it now that are looking at the data more like 10% at best? Was it really impossible to get data?

Now that you have an estimate, write it up and circulate it - It's risky: you could be volunteered to fix the problem and maybe you don't want that.

Would it really be impossible to monitor over the next year? (Still cheap data, cheap results - except if you really estimated 100% because now you were able to get real budget - even if too small - to attack it.)

Estimates, targets, budgets, deadlines are all different concepts. A fraught but carefully worked up estimate is rarely impossible.

Entire businesses get founded and funded on "impossible" estimates.

[awesome_dude]

Ah, I think that I get that, thanks.

Although to be clear, the estimates will "this is where we think that we will be saving money"

followed by a review (in 12 months time) that will be "this is what we think is the result, but it will include improvements from other vectors, such as better communication from business"

[creer]

Sure. This is rough engineering. If you identify a plausible significant cause, and you attack that, and you get useful improvement, people are not too likely to be overly concerned that there was some confounding factor in the improvement. If there is any excess, it's likely to be in the other direction: deciding that the likely improvement is not worth it. Engineers hate that kind of decision.

[awesome_dude]

We're really still no better off than where we started at - it cannot be measured, it has to be estimated, the estimates are only able to be validated after some time period has elapsed (1 - 5 years) and the confounding factors cannot be discounted.

I'm not arguing that we shouldn't I'm arguing that the business cannot put a number on it that it can rely on. That's fine if the budget is available, but if there's no budget, almost always for reasons beyond the engineer's responsibility (VC money, market resizing, etc) then you're really struggling to be able to justify it.

[creer]

What budget ever gets justified with exact numbers? What fantasy is this?

You get a fixed-price quote, you pay a fixed price amount, sure. But only because the vendor was planning to and is absorbing the uncertainty. Except if it was not really fixed price, then they send you a nice report explaining why it will cost you more in the end.

The future is great - so many estimates you can pick from!

> almost always for reasons beyond the engineer's responsibility

Now, you are touching to a different issue: If the project owner really wants to fund it, they will pick one estimate (or one end of the estimate). And if they really don't want to fund it, they will pick the other estimate (or the other end of the estimate). Either way, the issue will NOT be that the engineer couldn't cook up exact numbers. Even then, if by some sorcery you really need an exact number, just find a vendor willing to quote you a (very high) fixed price.

[creer]

Separately from "accurate", I would also argue that if the improvement you are proposing is slim or difficult to distinguish from other ongoing ambient improvements - then perhaps you shouldn't try to bring it up as a stand alone project. It's not worth it. "Slim" is not enough impact. You could bring it up as part of a package of other improvements - like those generated day in, day out by a methods or build group. They should be the ones championing small ongoing improvement - and they have an umbrella "do what you can" budget for that.