Over a million developers have joined DZone.

The Best-Laid Plans of Mice And Men

DZone's Guide to

The Best-Laid Plans of Mice And Men

Discover what the real culprit is behind your inability to correctly estimate the time your project will take, and how you can combat it.

· Agile Zone ·
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

In 1957, the commissioning of the Sydney Opera House began. The project was to be complete on Australia Day, January 26th, 1963, at a cost of £3.5 million ($7 million AUD, Australia used pounds up until 1966). Construction started on the 2nd of March, 1959.

Well, 1963 came and went, the Sydney Opera house was not complete. It would not be completed until 1973. It was 1357% over budget, $102 million and 10 years late.

Why is it that no matter how much we try to plan, we always run late? Does this mean that we haven't planned enough? Does this mean that we haven't worked out every contingency? Well, actually it does, but it is not our fault. It is a psychological phenomenon called the "Planning Fallacy." This was was the subject of a recent podcast on Freakonomics Radio. (Thanks to @stefanw and his mail outs for Age Of Product for letting me know about the podcast.)

I was so intrigued by the subject because recently I gave an estimate of 3 days for a piece of work; 2 weeks later, I'm still working on it. So I decided to do a bit more research on the topic and read a few papers by Roger Buehler who appeared on the podcast and a few other sources of information.

The Planning Fallacy

The "Planning Fallacy" was first proposed by Daniel Kahneman and Amos Tversky in 1979 in their paper, "Intuitive prediction: biases and corrective procedures ". It doesn't matter how intelligent you are, it doesn't matter if you are aware of the Planning Fallacy. If you are going to predict the cost and time of a piece of work that you yourself are going to undertake, you will most likely underestimate the amount of effort required.

Why is this? According to research, the simple reason is that we are optimistic. Even if we break down work, try to determine how long each piece is going to take, and how much it is going to cost, we usually underestimate because we only think of the best case scenarios. This optimistic view of things is called "Optimistic Bias". We basically think that things will go better than they really will.
Even if we are told otherwise, we will dismiss the negative views and go for the optimistic views. "That is not how it will occur, we will finish in 6 weeks, not 6 months like other projects!" and yet 6 months later, the project is near completion.

Even when we see that our plans are falling apart, we start to blame external factors. "The server crashed!", "We didn't see 'event' coming!" When it comes to planning the next project or task, we gloss over the past negative events and dismiss them as one-offs. They won't affect us this time.

This is a type of thinking where we only look at what is in front of us. For example, when we break down the work into components, then make up a scenario on how we will implement them is called the "Inside View," according to Roger Buchler. We fail to consider alternative views. We focus on the end and ignore other events that may occur. We see the future and the past through rose-colored glasses.

The other view is the "Outside View." This is where we look at external factors. "How have similar projects like this gone in the past?" The best way to think this way is as an outsider, someone not involved with the task, someone who has no emotional bearing on the task. An outsider for the simple reason that they do not have the emotional attachment and thus more likely to take in external factors such as past performance of similar tasks and experience of others, therefore, giving a better estimate than a person on the inside.

Improving Planning Accuracy

So how can we improve our planning accuracy?

Adding incentives to improve predictability actually improves the prediction more than the result. We tend to become more optimistic. So, when you add rewards for completing on time, people tend to think they will finish a lot sooner than they really will, or would have originally predicted if there was no incentive in the first place. Actually, incentives can backfire where people intentionally give incorrect estimates in the first place. For example, when bidding on a piece of work, the idea is that bidding under time and cost will win the job, then the contractor will charge through the nose for any inevitable changes that occur. This seems to be standard practice for any tender process. Its built into the system: anyone who gives a realistic estimate is outbid by those who do not. So, in order to get the work, you must play the game.

The only real way to improve accuracy is to actually base your predictions on past performance. This means that you need to record the data of the projects and tasks that you do. Then work out an algorithm to predict the outcome of future similar tasks.

The more tasks/projects you do, the more you tweak your algorithm and add data, the better your estimates get. This is why when you buy something on eBay, they ask when you receive the order through the mail. This data goes back into the eBay algorithm to predict when a future order will be received. It is not a guarantee, but the results become more accurate the more data that is added.

This is one of the reasons why in Agile methods such as T-Shirt sizing or story points comes into play. This is a method to group work into categories based on the amount of effort they will take. Extra Small, Small, Medium, Large, Extra Large, etc. Then by recording the time that each task of a similar "size" takes, you gain a reference point as to how future tasks of a similar "size" will take. The more iterations you do, the better you get at estimating the relative size of each piece of work. As you do the work, the time spent on each size is recorded and feeds back into the previous iterations recordings, giving you a better idea on how long future work will take based on your current estimate on the effort. You still do not get an accurate measurement, but you end up with a better measurement than just by guessing time in the beginning, unless of course, you are really good at estimating time in the first place.

How do you do your planning? Do you have a mechanism in place to review your estimates to see if they were accurate? Do you plan in a different way? Please let me know in the comments.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

agile ,prediction ,estimations ,scrum ,planning accuracy ,planning fallacy

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}