On: When did estimates turn into deadlines?

[nextworddev]

Multiply your original estimate by 3, works most of the time

[dredmorbius → nextworddev]

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 → dredmorbius]

> (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 → dredmorbius]

So 1 year -> 2 decades?

[dredmorbius → makz]

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 → nextworddev]

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 → dsego]

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 → nextworddev]

I prefer pi myself. For the sort of false precision that managers love.

[theamk → nextworddev]

I've heard "multiply by 2, use next time unit" rule. So 1 hour -> 2 days, 2 weeks -> 4 months, etc..

[loloquwowndueo → nextworddev]

Montgomery Scott recommends 4 instead.

[ben_w → loloquwowndueo]

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 → ben_w]

> 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 → mmcdermott]

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 → loloquwowndueo]

By the book admiral, hours could seem like days.

[rectang → nextworddev]

Multiply by π — it's more accurate.

[Moru → rectang]

Accurate and precise is different things :)

[rectang → Moru]

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.