As a part of my project management course I frequently have to talk about the estimation-related phenomenon known as "optimism bias". Succinctly stated optimism bias is described as follows:

We as the species of homo sapiens tend to overestimate our abilities required to perform a specific task and underestimate the complexity of the task in question

Usually when one provides his audience with a complicated and slightly boring definition, he has to follow up with a clear, simple and hopefully entertaining example. Throughout my consulting and teaching career I tried using a number of case studies including pretty much every megaproject on this list. However each and every example used has been met with mixed feelings. Sometimes people never heard about the Denver Airport Baggage Handling system and sometimes they failed to see the connection between optimism bias and the overall project failure.

I kinda gave up on finding the best illustration for this phenomenon, until one of my friends told me the following story:

His son has just started going to the kindergarten and he and his wife agreed that he would pick them up from the bus station located not too far from their home. They have also agreed that his wife would give him a call once she was ready to leave the office (kindergarten was located nearby). So at one point of time he receives a call from his significant other stating that he should pick them up at the bus stop in 15 minutes. Being a responsible person he exits his home right away and arrives at the bus station with 5 minutes to spare.

Five, ten, fifteen, thirty minutes go by. No sign of his wife and kid. Finally forty minutes after the expected deadline (sorry for the project management nerd talk) his family exits from the bus ... The following conversation ensues:

H: Where have you been? I have been waiting here for more than half an hour! And more importantly, why did you tell me it would take you 15 minutes to get here?

Today I wanted to share a very interesting story that, in my opinion, demonstrates the importance of asking questions while working on the projects. This example comes from my personal experience while working at an IT department of a very large international financial institution.

My boss: “Risk Management is having problems with their desktop statistical analysis software. They are asking for an Enterprise Edition of the software and a dedicated server. Our initial ballpark estimates for this project are at $500,000 and we have neither the money in our budget, nor the resources to accomplish that. You mission is to explain to them that they are not getting this stuff in the next couple of years!”

Me (going over to the Risk Management Department): “What is the problem?”

Risk Management people: “We have to store files on the shared server because of the privacy laws and access them through our desktops. Processing times are very slow. We have to upgrade to the Enterprise Server Edition and get a new server”

Me (calling Network and Infrastructure people): “But why is the processing slow? Is it the network issue or the overloaded server?”

Network people: “We checked the network and it does not appear to be overloaded”

Infrastructure people: “Are you kidding me?! The entire building is using this server. Of course it is overloaded and slow”

Me: “So, what can we do?”

Infrastructure people: “We will give them a dedicated NT server; we have one lying around here somewhere …"

Result: The $500,000 project was diminished to a $2,000 server and 3 man-days of work-problem solved.

Introduction

I have recently been contacted by one of my blog readers who asked me a very interesting question:

What are the estimation accuracy norms for different phases of the projects?

I found this question to be so interesting that I decided to dedicate my next posting to this particular topic. But in order to answer this question in full, let us start at the very beginning, the definition of the estimate itself.

The Definition of the Estimate

According to the Guide to the Project Management Body of Knowledge (PMBOK) published by the Project Management Institute the estimate is:

An assessment of the likely quantitative result.  Usually applied to project costs and durations and should always include some indication of accuracy (+/- x percent)

Think about this definition for a while ... If we are to believe the opinion of one of the leading project management institutions in the world, then a single number, say, "9 months", "$100,000" or "350 man-months", is not an estimate. However, statements like "9+/-3 months" or "$75,000 to $125,000" are indeed true estimates.

While this fact is well-known to any experienced project manager, many executives, sales, marketing and operations professionals are frequently very surprised when this piece of information is brought to their attention.

Let us try to explore some more and find the root causes of this phenomenon.

There is Uncertainty in the Estimation Process!

We must understand that there is almost always a serious degree of uncertainty in the estimation process. Here are just some of the questions that can never be answered at the very beginning of the project:

Prologue

I remember an episode from my early career. I got hired as an independent consultant to run a project for a Canadian software company that was doing a project for a much larger US organization. Right at the very beginning of the project we did a high-level estimate with the help of our sales team and came up with a budget of $1.5 million. The customer rejected the number and claimed that they would be able to pay only $750,000. Our company's management agreed (don't ask me why) with the new "forecast", contracts were signed and the work commenced.

Several month later, once we had the detailed requirements document on our hands, we went through the estimation exercise again, this time the bottom-up version. The number we came up with? The same $1.5 million. We felt it would be the right thing to do to go back to the presidents of both organizations and let them know about the results of our findings ...

The reaction from the client's side has been very interesting to say the least. "We feel that Jamal is overly pessimistic in his approach, and we want him to be replaced with a more confident project manager!"

We Still Suck at Estimating

We all know about the famous examples of projects being grossly over budget and late. These include:

• The Denver airport baggage handling system that required an additional 50% of the original
  budget - nearly $200m.
• Eurotunnel - an actual cost of £10bn, over double its original estimate of £4.9bn to build
• Virtual Case File (FBI) – scrapped after $170 million while delivering only 10% of the promised scope

What are the explanations for such colossal failures? Currently there are at least three different schools of thought on this topic:

• The Standard Economic Theory
• The "Mass Delusion" Theory and
• The "Machiavelli Factor" Theory

The Standard Economic Theory Explanation

The classical economic theory states that our high failure rates on projects are very simple to explain. If companies take rational risks in order to earn abnormal incomes, these poor outcomes are inevitable. One of the key laws of the financial theory states that in a perfect market, the higher the expected return of an asset, the higher is the inherent risk associated with it.

I have recently been running a project management workshop at one of the European banks and an interesting dialogue took place between one of the senior managers and me. He basically asked me the following question:

I have a feeling that our project managers constantly pad their estimates in order to obtain more breathing room and to make their lives easier than they should be. How does one address this issue?

In response I walked over to the next available flipchart and drew this figure (see Figure 1):

Figure 1

Me: When you assign projects to your project managers what do you usually ask of them?

SM: Well, I usually ask them to tell me how long on average this project should take ...

Me: (pointing to Figure 1) So, basically when they answer your question, they provide you with a "fair" estimate for this project. Do you realize that according to the laws of statistics, you have only a fifty percent chance of hitting that deadline?

SM: Oh, I never thought about it that way ...

Me: And we haven't even considered the optimism bias theory, that in a nutshell , states that humans tend to constantly  overestimate their abilities and underestimate the complexity of tasks at hand. So, in reality when they think that they provide you with a 50/50 estimate, they actually supply you with a deadline they have only a 20% probability to hit (see Figure 2)?

Figure 2

Me: So, as a project sponsor would you be comfortable with only a 20% probability of finishing on time?

SM: Absolutely not!

Me: So, what threshold would be satisfactory for you?

SM:  I guess at least 90% on most of my projects. And some of them would require even higher probability, say, 95 or 99% ...

Long time ago, when I was still working as a permanent employee, I was invited for a job interview by a local software product company. I arrived at their headquarters and was led to the conference room where I was greeted by the CEO, VP of Marketing and the CTO of the organization.

The interview went on without any surprises; I was asked to tell a little bit about myself, then the CEO told me about the current projects the company has been involved in lately, followed by the overview of the key products produced by the firm provided by the vice-president of marketing.

The CTO has been sitting quietly until that moment, but suddenly he shifted in his chair, looked at me somewhat intensely and the following conversation took place:

CTO: (looking at a copy of my resume) I see you don’t have any technical background …

Me: Well, I did work as a business analyst for a while, before taking on both the project management and requirements engineering roles at most of the companies I worked at.

CTO: That’s not what I meant. What I was trying to say is that you don’t have any coding experience.

Me: Oh, no … My educational background was in finance and management science.

CTO: How are you going to work with our developers then?

Me: I am sorry, I am not sure what you mean …

CTO: Well, you assign a task to the programmer and he tells you that it would take five days to accomplish it. How do you know he is not lying to you and it would take him only two days? He could spend the rest of his time on Facebook or YouTube …

I have to admit this was neither the first nor the last time I heard a variation of this argument in my project management career. Thus, I think it is time to make two very important points about this topic.

American troops, on the other hand, had a much tougher challenge: the occupation of the mountainous centre and western half of the island. Nevertheless, the American Seventh Army was able to reach the north coast of Sicily in only seven days and with hardly a shot fired. What allowed the US troops to accomplish "the fastest blitzkrieg in history", as General Patton once described this campaign?

According to some historians, the American government managed to strike a deal with the most powerful man on the island, the capo di tutti capi of the Sicilian mafia - Don Calogero Vizzini. The US Office of Strategic Services (OSS) - the wartime predecessor of the Central Intelligence Agency (CIA) - recruited Charles "Lucky" Luciano to act as an intermediary between the advancing US Army and "La Cosa Nostra". As a result of these negotiations, the mafia protected the roads from snipers, arranged enthusiastic welcomes for the advancing troops, encouraged mass desertions from the Italian army and provided guides through the confusing mountain terrain.

One might wonder what events lead to such an unlikely alliance between the Allied forces and the mafia chieftain? A negotiating expert would call this situation "a value-creation exercise in negotiations". This was a classical case of proverbial synergy, where two sides stood to benefit immensely from one shared goal - the liberation of Sicily from fascists. The benefits, derived from this partnership, however, were quite different but surprisingly congruent.