Multiply your original estimate by 3, works most of the time
Montgomery Scott recommends 4 instead.
When did estimates turn into deadlines?
11–20 of 237 posts
Re: When did estimates turn into deadlines?
#12Multiply your original estimate by 3, works most of the time
Multiply by π — it's more accurate.
Re: When did estimates turn into deadlines?
#13Working in smaller steps is how you should build software. Constantly get feedback and re-evaluate what you're working on with other members of the team. Instead of giving an estimate, use t-shirt size.
With constant feedback, the whole team is participating in the emergent complexity, instead of being passive and just annoying you with "is it done yet"?
Re: When did estimates turn into deadlines?
#14I normally only commit to "We will give an update in X (minutes/hours) to make sure we understand the problem first. Then start giving estimated timelines in ranges with specific call outs for updates and possible changes to the timeline.
I've found that most management just want to be involved in the process and have definite times set for updates and can handle timeline changes as long as information is coming at regular intervals.
Re: When did estimates turn into deadlines?
#15Multiply your original estimate by 3, works most of the time
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.
Re: When did estimates turn into deadlines?
#16Re: When did estimates turn into deadlines?
#17Multiply your original estimate by 3, works most of the time
Montgomery Scott recommends 4 instead.
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.
Re: When did estimates turn into deadlines?
#18My technique is to give an estimate with error bars. Something like 6 weeks plus or minus 2. That then leads into discussion as to what is unknown/undefined leading to the uncertainty. Sometimes the error bars are larger than the estimate because I know there will be endless feature creep and UI revisions for something like "analytics". And sometimes the number could be negative like 6 weeks plus or minus 8. That is when the functionality already exists (eg the data is already there - you can already load it into Excel and a pivot table) and could be sufficient.
Re: When did estimates turn into deadlines?
#19One trick, if you can get away with it, is to ensure that you are always estimating for a fixed scope exclusive of unknown unknowns.
You should not provide an estimate for "feature X implemented", but rather for "feature X engine". If you discover additional work to be done, then you need to add "existing code refactor", "feature X+Y integration", etc. as discovered milestones.
Unfortunately, you need that nomenclature and understanding to go up the chain for this to work. If someone turns your "feature X engine" milestone into "feature X complete" with the same estimate, you are screwed.
------
There is a related problem that I've seen in my career: leadership thinks that deadlines are "motivating".
These are the same people that want to heat their home to a temperature of 72F, but set the thermostat to 80F "so it will do it faster".
I was once in a leadership meeting, where the other participants forgot that I, lowly engineer, was invited to this meeting. Someone asked if we should accept that deadline X was very unlikely to be met, and substitute a more realistic deadline. To which the senior PM responded that "we never move deadlines! Engineering will just take any time given to them!"
Engineering, in that case, gave the time back when I left that team.
Re: When did estimates turn into deadlines?
#20The article is about modernization projects, which have soft deadlines because ostensibly the legacy software is still running while you're developing the replacement. There's always budget pressure, and promises may have been made, and users may be hoping for new features and eliminated frustrations... but if the replacement is a day late, it really wouldn't matter much.
Conversely, if you're trying to launch a space probe and the planets are no longer in the right positions for the required gravity assist, your spacecraft will not get where it needs to go. Or if you're a little $100M/yr toolmaker, and Ford asks you for a die for the 2026 F150 production line, to be delivered by March, and the contract states you owe a $20,000 per MINUTE penalty if you're late...you don't wait until February to say something surprising happened and it's not going to be ready. You don't sign on that dotted line unless you know for certain that you can do it.
Ford or NASA won't bat an eye when you tell them that a quote is going to cost $XX,XXX. They won't be surprised when they give you an ECO and you say that it's going to take 3 weeks and $8,000 to deliver a part that everyone knows you can probably make by hand in 30 minutes, they know that you're hedging against those deadlines, and pricing in the acceptance phase and inspection phase and contingency plans and everything else that makes their deadline-heavy industry function.
But if you tell someone at OP's modernization group that due to incomplete information you think that the 30-minute task to change the text of that button will take "no more than 3 weeks and $8,000" they'll laugh you out the door. Optimistic estimates get rewarded, pessimistic estimates get discouraged, accurate estimates are irrelevant, and in the end you're constantly behind schedule and no one's really surprised.