3 ms·
For projects with a deadline that matters, I've found that explicitly estimating to "80%" likelihood has helped me hit deadlines much more consistently. I used
by danpalmer 5y ago
For projects with a deadline that matters, I've found that explicitly estimating to "80%" likelihood has helped me hit deadlines much more consistently. I used this to hit a deadline on a 4 month software project only 10 days out, which I think is good for software.
I think implicitly most estimates are the 50/50 case. "I'm 50% sure I can do it in this time". Much of the time I don't think this is very useful, and isn't very well thought through.
- noduerme 5y agoYou have to assume you're going to hit a brick wall at least a few times in any given project, and something you thought would be a snap turns out to require days of refactoring. Especially if there's some aspect of business logic that wasn't clearly communicated beforehand and/or the customer hadn't considered until it came to light as a code problem. This should be built in to the estimate, but always come as a surprise gift to the customer when you still manage to deliver it on time. In design and code, customers need to be consulted and asked what they wanted and made to feel important but not about anything actually mission critical. That's what you're hired for. At least a few times in any long project you need to come up with a meaningful sounding but essentially empty aesthetic decision for the customer to make. This allows you to both show progress and let them feel they're in control. It also allows you to extend the deadline if you feel yourself behind.
- regularfry 5y ago50% is optimistic. Some (ok, many) estimates are actually 1% projections. The soonest we could possibly be done. This, too, is not very useful.