3 ms·

>The idea that it’s possible to have a project with no budget or time constraints just isn’t often the reality of the situation. It must be possible because mo

by foldr 4y ago

>The idea that it’s possible to have a project with no budget or time constraints just isn’t often the reality of the situation. It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost. Time is almost always more flexible than the people imposing the deadlines think that it is. As for budget, you just have to choose to keep spending more, or to stop (or wait till you run out of money). Making up an estimate beforehand doesn't alter that process. If management were really in the business of setting budget and time constraints, projects would constantly be getting canceled because they went $100 over budget or a week over time. In reality we all know what usually happens: the project simply continues; the estimates, deadlines, etc. are shifted.

Closi 4y ago
> It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost. Making decisions on the basis of an estimate which could be plus or minus 50% is fine. It’s better than making a decision on the basis of nothing at all, and then managing the project with no clue about how long it should be taking or costing. > If management were really in the business of setting budget and time constraints, projects would constantly be getting canceled because they went $100 over budget or a week over time. This isn’t the idea of estimates - the main idea is so you can effectively allocate resource and understand cost/benefit. All companies have limited resources and must decide if they want to focus on feature A or feature B, and part of that decision will be the likely cost, risk, and timeline to deliver. You aren’t going to cancel a project when it goes (a bit) over budget because the development costs to date are already sunk (ie you only now need to consider remaining development effort in the cost/benefits calc) and the benefits are probably still the same.
- foldr 4y ago
  But most estimates are completely wrong (much worse than +/-50%). Only accurate estimates can possibly be useful for planning, and very few estimates of time and cost for software projects are accurate.
  - Closi 4y ago
    > Only accurate estimates can possibly be useful for planning Nah, a best guess estimate is better than no estimate at all. If engineers don’t estimate it doesn't mean estimates go away, it just means they have moved responsibility of estimating away from the engineers to the management team (who will then need to make their own estimate of how difficult/expensive something is to do and how long it will take). Besides, you can be accurate without being precise - and engineers can work to become more precice over time as they gain more experience.
    - foldr 4y ago
      >Nah, a best guess estimate is better than no estimate at all. Only if it's more-or-less accurate on average. It can't possibly be the case that a highly inaccurate estimate is better than no estimate. If you don't know, you don't know, and you should plan on that basis, not on the basis of a made up estimate.

by foldr 4y ago

Closi 4y ago

> It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost. Making decisions on the basis of an estimate which could be plus or minus 50% is fine. It’s better than making a decision on the basis of nothing at all, and then managing the project with no clue about how long it should be taking or costing. > If management were really in the business of setting budget and time constraints, projects would constantly be getting canceled because they went $100 over budget or a week over time. This isn’t the idea of estimates - the main idea is so you can effectively allocate resource and understand cost/benefit. All companies have limited resources and must decide if they want to focus on feature A or feature B, and part of that decision will be the likely cost, risk, and timeline to deliver. You aren’t going to cancel a project when it goes (a bit) over budget because the development costs to date are already sunk (ie you only now need to consider remaining development effort in the cost/benefits calc) and the benefits are probably still the same.

foldr 4y ago
But most estimates are completely wrong (much worse than +/-50%). Only accurate estimates can possibly be useful for planning, and very few estimates of time and cost for software projects are accurate.
- Closi 4y ago
  > Only accurate estimates can possibly be useful for planning Nah, a best guess estimate is better than no estimate at all. If engineers don’t estimate it doesn't mean estimates go away, it just means they have moved responsibility of estimating away from the engineers to the management team (who will then need to make their own estimate of how difficult/expensive something is to do and how long it will take). Besides, you can be accurate without being precise - and engineers can work to become more precice over time as they gain more experience.
  - foldr 4y ago
    >Nah, a best guess estimate is better than no estimate at all. Only if it's more-or-less accurate on average. It can't possibly be the case that a highly inaccurate estimate is better than no estimate. If you don't know, you don't know, and you should plan on that basis, not on the basis of a made up estimate.