4 ms·

I agree with that estimates are largely about a [false] sense of control, but this is a tough sell when dealing any company with budgets and stakeholders that h

by swanson 13y ago

I agree with that estimates are largely about a [false] sense of control, but this is a tough sell when dealing any company with budgets and stakeholders that have to go ask their boss for a finite number of dollars to trade for software. Often times, this is a one-time ask. You get money allocated once, so you better get enough to build the whole thing. You can't go back and say, "hey boss! look what we got with the first $10k, can I have $10k more?" If you are a startup or dealing with a 4-figure project from a local business, then sure, you can probably skip estimates.

robinhoode 13y ago
> Often times, this is a one-time ask. You get money allocated once, so you better get enough to build the whole thing. You can't go back and say, "hey boss! look what we got with the first $10k, can I have $10k more?" This is an area where software engineers who've made serious profits and turn around to become investors have an edge over traditional that do not understand the levels of risk involved with large software projects. Explaining the granularity in the types of risk that are involved is complicated to people that expect to write a check once and have a finished product come out of it.
wpietri 13y ago
Sure, but that's an artifact of traditional budgeting. In the Lean world (as in Lean Manufacturing), traditional budgeting is considered a dangerous and misleading activity. Another way to work it is to have a backlog of valuable things to do that get handed out to teams. When somebody needs something to do, you pick the highest-ROI project from the backlog and give it to them. In that context, detailed specs and careful estimates generally turn out to be wasteful. If you're trying to pick projects by expected ROI, then making the software estimate more precise than the (generally handwavey) business value estimate is pointless.
- facorreia 13y ago
  > you pick the highest-ROI project from the backlog How do you calculate the return on investment without estimating the investment?
  - Anchor 13y ago
    You don't have to know the ROI value of each project, just compare their relative sizes to select the best from the set of projects with the highest profit ranking. This assumes, though, that the best of the projects is worth building in the first place.
    - jacques_chester 13y ago
      How do you know their relative size? Isn't that an estimate?
  - wpietri 13y ago
    Well, one option is time-boxing. You say, "We'll put a team on this for up to two months: they get done what they get done." It's a fixed investment; it's up to the business stakeholders to judge what kind of return they can get out of that. But in the this context, by "estimation" I mean "formal estimation". Having developers glance at something and ballpark it is basically a zero-cost activity. As long as that I number has about the same error bars as your R number, then it's perfectly fine for ROI. Especially given typical requirements volatility, and a project approach that sharpens ROI estimates as you go.

by swanson 13y ago

robinhoode 13y ago

> Often times, this is a one-time ask. You get money allocated once, so you better get enough to build the whole thing. You can't go back and say, "hey boss! look what we got with the first $10k, can I have $10k more?" This is an area where software engineers who've made serious profits and turn around to become investors have an edge over traditional that do not understand the levels of risk involved with large software projects. Explaining the granularity in the types of risk that are involved is complicated to people that expect to write a check once and have a finished product come out of it.

wpietri 13y ago

Sure, but that's an artifact of traditional budgeting. In the Lean world (as in Lean Manufacturing), traditional budgeting is considered a dangerous and misleading activity. Another way to work it is to have a backlog of valuable things to do that get handed out to teams. When somebody needs something to do, you pick the highest-ROI project from the backlog and give it to them. In that context, detailed specs and careful estimates generally turn out to be wasteful. If you're trying to pick projects by expected ROI, then making the software estimate more precise than the (generally handwavey) business value estimate is pointless.

facorreia 13y ago
> you pick the highest-ROI project from the backlog How do you calculate the return on investment without estimating the investment?
- Anchor 13y ago
  You don't have to know the ROI value of each project, just compare their relative sizes to select the best from the set of projects with the highest profit ranking. This assumes, though, that the best of the projects is worth building in the first place.
  - jacques_chester 13y ago
    How do you know their relative size? Isn't that an estimate?
- wpietri 13y ago
  Well, one option is time-boxing. You say, "We'll put a team on this for up to two months: they get done what they get done." It's a fixed investment; it's up to the business stakeholders to judge what kind of return they can get out of that. But in the this context, by "estimation" I mean "formal estimation". Having developers glance at something and ballpark it is basically a zero-cost activity. As long as that I number has about the same error bars as your R number, then it's perfectly fine for ROI. Especially given typical requirements volatility, and a project approach that sharpens ROI estimates as you go.