The book Gödel, Escher, Bach: An Eternal Golden Braid (Douglas Hofstadter, 1979) offered up Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
Back in the 19th century, Vierordt’s Law claimed, roughly, that the longer a task will take, the more likely it is to be underestimated.
Why are projects so often late? I heard a PMP instructor – a seasoned project manager and mentor to others – say that despite years of project management experience, a project that’s only a few weeks late instead of months late is still a rare thrill.
In my experience, two factors account for an awful lot of project lateness, but – strangely – almost nobody mentions one of them. One is that people underestimate. The other is in the math of probability.
The commonly cited factor for project delays is the strong tendency to underestimate.
Research from 2007 (“Bias in memory predicts bias in estimation of future task duration“) found that “underestimation is most likely when a task is well learned.” That seems counter-intuitive, because you’d think that the better you know a task, the better you’d be at estimating the time needed. The study, however, found that people tend to underestimate how long something took in the past, and that makes them underestimate how long it’ll take in the future.
An effect I’ve observed is that people often estimate task length as if nothing will go wrong. To me, this is like my GPS unit that never accounts for traffic lights in its time estimates. Estimating as if everything will happen without delay means your estimates are probably low.
Similarly, there’s what I call the “MapQuest effect.” (Or fill in your favorite mapping tool.) This means estimating the main activity while ignoring all the lesser activities that go with it. If I get driving directions from my suburban home to a particular downtown DC office building, MapQuest tells me it’ll take 30 minutes. If I want to be at a meeting that starts at 2:00, what’s my chance for success if I plan to leave home at 1:30? Non-existent. Even without traffic problems, I’ve left out any possibility of last-minute delays in leaving the house, and I’ve left out the time needed to find parking, walk to the office building, reach the reception desk, and get to the meeting space.
Another underestimating effect I’ve observed is that people feel pressured into promising more than they can deliver. Even though “fast” and “good” are often not the same thing, people often feel compelled to give short estimates to show they can handle a task quickly. It’s almost as if they’re admitting to a shortcoming if they don’t make their estimate as short as possible, so they go with the shortest possible estimate instead of something more realistic.
The other factor, which hardly anybody considers, is simple probability.
Many people figure that to estimate the overall project duration, you just add up the tasks that make it up (along the critical path), and there’s your estimate. Turns out, the probabilities are against you.
Here’s a thought experiment. First, what would you say your on-time percentage is? That is, what percentage of your tasks are completed within the time you estimated? I’m talking about the task level, not the overall project completion estimate – the pieces you’d estimate individually before you come up with the grand timeline.
I’d say that most people are no higher than 50% at finishing tasks within their estimates. Unfortunately, if your ability to estimate task length is weak, then your ability to estimate your on-time percentage is probably weak too. Darn.
But anyway, suppose you credit yourself with a 90% on-time rate. Nine times out of ten, you complete a task within the time you thought it would take.
For the second step of this thought experiment: How many tasks would you typically string together sequentially as part of an overall effort? This might be the number of tasks on the critical path of a project plan, or it might be your sequence of activities trying to get out the door before a vacation. Suppose you pick eight steps for this exercise.
So now you’ve got eight steps, and you’re 90% likely to be on time for each of those steps. Maybe you estimated two hours each for the first four, and four hours each for the last four. That’s a total of 24 hours. What’s the probability the whole effort will need 24 hours of effort?
In other words, what’s the probability of hitting 90% eight times in a row? You can calculate that by pasting this formula into a Google search box: 0.9^8. The answer is 43%. That’s worse than 50/50.
In other words, even if you’re pretty good at estimating each of the eight tasks, this project is likely to be late.
Adding up the task estimates to find the total estimate is a bad bet.
What’s the Fix?
There’s an old tongue-in-cheek rule of thumb that says you should double the number and increase the units (24 hours becoming 48 days, for example). But that’s not very realistic or helpful.
PERT Three-Point Estimate
A commonly offered fix is the PERT three-point estimation technique: (optimistic + 4*likely + pessimistic) / 6. You’re making three estimates: the optimistic estimate for when nothing goes wrong, the pessimistic estimate for when a lot goes wrong, and the estimate you consider most likely.
As an example, say you’ve originally estimated a task at 2 hours, assuming everything goes pretty smoothly. That’s now your optimistic guess. Maybe your pessimistic guess is that you could spend an extra hour and a half (3.5 hours total) if you find a surprise need for a trip to the store before you’re ready to go. Maybe your likely estimate is that you fudge in an extra half hour on top of your optimistic estimate for things like looking for lost keys and herding the cats (your passengers). The PERT estimate is therefore (2 + 4*2.5 + 3.5)/6, or about 2.6 hours.
At its best, the PERT estimate is an intelligent fudge factor to keep you from always using optimistic estimates. It gets you to think about what could go wrong, or what could delay you.
At its worst, the PERT estimate won’t be very good either. If you’re no good at making one estimate for a task, you might be no good at making three estimates for the task. The optimistic estimate might be hard enough to come up with, but it’s harder still to estimate what’s likely, and it’s hard to know how pessimistic you should be in your pessimistic estimate.
There’s still an element of probability in the PERT method. The task could still take longer than the PERT estimate suggested. The best we can hope for is that the PERT estimate is more realistic than our originally optimistic estimate. It’ll never be a guarantee.
Another possible fix is to track your actual time, so you can use historical data in your future estimates. This could get you past the experience bias that makes you underestimate past tasks.
That’s great if you can collect enough accurate data, and if your future efforts are comparable to your past efforts.
What if entering all that data is too tedious to do in a consistent and timely manner? Someone who enters their task data long after the fact might not be very accurate.
What if it’s hard to say how much time you really spent on a given task? If you operate in an environment that features lots of interruptions and distractions, knowing that you started a task at 9am one day and finished at 5pm the next day leaves a lot of leeway in estimating how much time you spent on one particular effort.
In other words, data’s great if you’ve got it, but it might not be complete, accurate, or relevant for the task you’re estimating now.
The Probability Fudge
If you’ve got a decent idea of your on-time rate, you could fudge your estimates up by dividing by your on-time percentage.
If you’re on time 80% of the time, make your estimate, then divide it by 0.8. Your estimate of 24 hours becomes 24/0.8 = 30 hours. If you’re on time 50% of the time, divide your estimate by 0.5. For those who don’t breathe math, that’s the same as doubling it. If your on-time rate is 50%, your estimate of 24 hours becomes 48 hours.
This too is a fudge factor, but it might help steer you to more realistic estimates.
My Best Advice: Set Expectations, and Update Them
Given that no method is perfect at fixing squishy time estimates, do you give up in despair? Do you let the delays happen, then whine about how it’s not your fault? Naaaah.
First, set realistic expectations for yourself. Recognize that your estimates won’t be perfect. Some tasks will go past their estimated durations.
Set realistic expectations for whoever will see the estimates. Talk about probabilities with them, even if you don’t have enough to data to gauge those probabilities precisely.
Importantly, update the expectations. “See it, say it” as they say in the DC subway system. If you see things heading toward delay, you’re generally better off by being up-front about it with whoever needs to know instead of waiting until the deadline to announce you’re going to be late.
Remember those eight tasks from our hypothetical example? At first, you had to get your 90% on-time rate eight times in a row. Finish one off, and now you need to hit 90% only seven times in a row. Then six, then five, and so on. Your accuracy in the overall project deadline should go up as you finish off the tasks that make it up.