| ▲ | nextworddev 7 days ago |
| Multiply your original estimate by 3, works most of the time |
|
| ▲ | dredmorbius 7 days ago | parent | next [-] |
| Heuristics I'd learned was "double the time and bump the unit". So: 2 hours -> 4 days, 1 week -> 2 months, etc. (I'm not sure where this turned up, but it's a long time ago, going on three decades.) The other option is to carefully track tasks, relevant dimensions, estimates, and actual performance, and see if there's any prediction modelling which can be derived from that. Problem is that this a classic instance of modelling in which the model itself affects the domain (as with economics and sociology, contrasted with astronomy and meterology where this isn't the case), such that estimates incorporating past performance data will incorporate the fact that the prediction model is being used. |
| |
| ▲ | natebc 6 days ago | parent | next [-] | | > (I'm not sure where this turned up, but it's a long time ago, going on three decades.) That means it was 1.5 years (wall clock) ago right? I like this method. | |
| ▲ | makz 6 days ago | parent | prev [-] | | So 1 year -> 2 decades? | | |
| ▲ | dredmorbius 6 days ago | parent [-] | | Yes. Note that this also comes out about the same if you're using months (12 months -> 24 years (2.4 decades)) and (at least within a factor of two-ish) weeks (52 weeks -> 104 months (0.867 decades). I'm not claiming this is accurate, I'm stating that it's a heuristic I'm familiar with. This may have been in Arthur Bloch's Murphy's Law and Other Reasons Things Go Wrong, though I'm not finding it in comparable collections. Possibly from project planning literature I was reading in the 1990s (DeMarco & Lister, Brooks, Boehm, McConnell, etc.). |
|
|
|
| ▲ | dsego 7 days ago | parent | prev | next [-] |
| Then you get the dreaded can you explain why it takes so long, or I asked engineer xyz and they gave a different estimate, where is the complexity etc. |
| |
| ▲ | Moru 6 days ago | parent [-] | | If you already asked someone, I'm not needed here so I'm going back to work on project Y that already is late enough. |
|
|
| ▲ | mandevil 7 days ago | parent | prev | next [-] |
| I prefer pi myself. For the sort of false precision that managers love. |
|
| ▲ | theamk 7 days ago | parent | prev | next [-] |
| I've heard "multiply by 2, use next time unit" rule. So 1 hour -> 2 days, 2 weeks -> 4 months, etc.. |
|
| ▲ | loloquwowndueo 7 days ago | parent | prev | next [-] |
| Montgomery Scott recommends 4 instead. |
| |
| ▲ | ben_w 7 days ago | parent | next [-] | | A friend suggests doubling the number and increasing to the next unit — hours become days, days become weeks, etc. I've certainly seen some environments — plural — where a task that should take 1 hour actually takes 2 days, and one that should take 2 days takes 4 weeks. | | |
| ▲ | mmcdermott 5 days ago | parent [-] | | > A friend suggests doubling the number and increasing to the next unit — hours become days, days become weeks, etc. I don't know. Going from 8 hours => 16 days seems like quite the markup. | | |
| ▲ | ben_w 5 days ago | parent [-] | | The biggest surprise to me was the project managers and leads who refused the opportunity for going from the big numbers to the small one by allowing a faster development architecture. |
|
| |
| ▲ | ikiris 7 days ago | parent | prev | next [-] | | By the book admiral, hours could seem like days. | |
| ▲ | 7 days ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | rectang 7 days ago | parent | prev [-] |
| Multiply by π — it's more accurate. |
| |
| ▲ | Moru 6 days ago | parent [-] | | Accurate and precise is different things :) | | |
| ▲ | rectang 6 days ago | parent [-] | | Of course you’re right, however: 1. If we’re talking about bamboozling people who are either ignorant or willfully obtuse, excess precision is a stupid but useful tool for getting a realistic multiple of 3x-4x past them. 2. If the target audience understands excess precision, the excess precision is a nice little in-joke to flatter them and acknowledge their cleverness. 3. The absurdity of the precision illustrates tha very imprecision of the estimate. |
|
|
