Yes, I am willing to make that bet without knowing anything about your project, your team, your organization, your timelines, or your budget. Here is why:
Activities within technology projects are usually so complex that if you were to repeat them under identical conditions, the time required to complete them would vary. After all, people are involved in performing these activities, and as you may know, the behavior of people is non-deterministic.
When you estimate or guess the duration of an activity, you’re really dealing with a range of possible outcomes. If plotted as a distribution, the actual results for a number of identical trials would have a shape such as that shown in the figure below. There’s a minimum duration, a most likely duration, and a maximum duration.
The shape of this distribution varies with the nature of the activity. For example, if you’ve done the activity many times and everything involved in it is fairly predictable, the minimum and maximum duration are close together. Though the distribution is probably very narrow.
If the activity has never been tried before and some aspects of the execution are poorly understood, the minimum duration and maximum duration might be more widely separated. Our time needed for the activity could be quite variable.
For example, setting up a GitHub repository is an activity that’s well understood (at least by most developers). If you measure the time required by experienced professionals to setup such a repository, you would probably arrive at a fairly narrow distribution. On the other hand, building your own source code repository is an activity that is not well understood. The distribution of durations for that activity are more likely to be fairly broad.
Distributions for the duration of less predictable activities have another significant feature. Although the minimum duration is probably well below the most likely duration, the time between them is usually far less than the time between the most likely duration and the maximum duration. The distributions are likely to have shapes like the one below.
These long-tailed distributions are very normal. While there are some pretty hard limits on how fast things can be done, there are no limits on how slow things can be done. For example, no matter how hard you try, you probably cannot get your Windows laptop booted and working with a projector in less than 2 minutes; even if you pray. But even without trying, it can sometimes take you 20 minutes, even though it’s only a small security update that is installing.
If you’re prudent, you leave a little extra time to get yourself ready for presenting in that important meeting, and even then, you’re just screwed.
This is just a small example. Now imagine the distribution of times required to integrate and test a complex API. If all goes well, it might take four weeks; rarely less. But if things don’t go well, it could take months.
Why am I so sure it rarely takes less? I take into account Parkinson’s law.
Work expands so as to fill the time available for its completion.
So Why Are Projects Always Late?
The answer is that the estimates most of us make for the duration of an activity are of the «most likely» type. That is, we tend to use as an estimated duration for the most likely value of the duration. Since the most likely value of the duration is usually less than the mean duration, for most distributions in real life, we tend to bias our estimates towards the short end of the distribution, as illustrated below.
For a single activity, this isn’t good, but it isn’t a disaster. True, on the average, your performance would be less than stellar. Depending upon the exact shape of the distribution, you would find that typically, you would be underestimating the actual duration by about 10-20%.
The problem becomes much more severe when you look at projects in which the project duration is the result of several such underestimates, in a series, as would be the case along the critical path of a complex technology project. If you’re significantly late on some activities, no amount of early delivery on other activities can compensate for it.
The Planning Fallacy
What I described above is one possible explanation for what is also known as the planning fallacy. First proposed by Daniel Kahneman and Amos Tversky in 1979, the planning fallacy is a phenomenon in which predictions about how much time will be needed to complete a future activity displays an optimistic bias and underestimates the time required.
This phenomenon sometimes occurs regardless of the individual’s knowledge that past activities of a similar nature have taken longer to complete than generally planned.
Or as Hofstadter ’s Law formulates it:
It always takes longer than you expect, even when you take into account Hofstadter’s Law.
The bias only affects predictions about one’s own activities. When outside observers predict activity completion times, they show a pessimistic bias, overestimating the time needed.
In 2003, Lovallo and Kahneman proposed an expanded definition as the tendency to underestimate the time, costs, and risks of future actions; while at the same time, overestimate the benefits of the same actions.
According to this definition, the planning fallacy results in not only time overruns, but also cost overruns and benefit shortfalls.
Closing Thoughts
The above is why I will make the bet blindly; statistics seem to support my bet. According to multiple sources (KPMG Project Management Survey 2017, Standish Group Chaos Report 2015) more than 20% of large technology projects fail outright and another 50% are over time and budget. Also, the failure rate of projects with budgets over $1M is 50 percent higher than the failure rate of projects with budgets below $350,000 (Gartner).
Funny enough, almost 100% of all project managers and sponsors believe their project belongs to the other 25%.
In one of my next articles I will discuss some measures you can take to help mitigate the planning fallacy and make better estimations.
