[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.