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% ...

CIO New Zealand

By Hemant Kogekar

05 December, 2013 11:46

You have probably read about the Queensland Department of Health payroll project, which ended in debacle with costs estimated at $1.2 billion. In the US, the Expeditionary Combat Support System project was cancelled after the US Air Force spent $1bn on its development.

The sad fact is these failures are not isolated instances; they’re just the most visible. Based on industry norms, less than 50 per cent of IT projects finish on time and on budget.

Discussions with experienced CIOs, consultants and project managers indicate there are many reasons for the failure of IT projects. If you step back from the individual causes, common themes emerge. A few are obvious; others are not well recognised.

Fuzzy goals: Many large projects fail because what they are trying to achieve isn’t made clear enough. There is no clear problem definition or clarity about the requirements, and the full scope of the project is not understood. One executive has an objective, but as the project moves forward new people, such as other executives, risk managers, and architects are introduced, adding their ideas of what would be best. The net result is unclear goals, expanding project scope and poor project design, all of which lead to unending debates and sliding timelines.

Over-optimism: Salespeople and internal project champions both want their proposal to succeed. However, in their desire to make the ‘sell’, they often underestimate the costs and over-emphasise the benef its. While preparing business cases, there is a tendency to maximise benefits and reduce costs to achieve the right return on investment (ROI). At times, this under-estimation is not intentional, but a result of the CIO having a poor understanding of the current situation and requirements. The CIO does not consider, or budget for, the effort to move from installing a system to actually achieving the benefits (new products, customers, capability).

Over-optimism results in unrealistic schedules. There is often an unjustified faith in technology (product, vendor or internal capability). Solution complexity is not evaluated either.

I once taught a one-day project management workshop for a group of executives of a large international bank. The people present in the room were the CEO, COO, CMO, CIO, VP of HR and the CFO. We started discussing how the projects that only ten years ago were pure IT initiatives now have grown and span across the entire organization and involved resources from every department. An interesting exchange took place between me and the CEO of the company:

CEO: Yes, all you are saying about the importance of project management is very interesting, but we have decided long ago that our organization simply can’t assign a project manager to run an enterprise project.

Me: How so?

CEO: Well, here is our logical chain of thought. The project manager must be a technical expert in the domain of his project. Our projects, as was mentioned earlier, span across multiple departments including, finance, accounting, payments, risk, HR, marketing, etc. Since we can’t find a person who would be an expert in all these domains (frankly, I don’t think such person even exists in the entire world), we can’t have a project manager assigned to the project. We will have to rely on the departments coordinating the activities among themselves …

Me: OK, I understand you reasoning … With you permission, can we look at this problem from a different perspective?

CEO: Sure!

Me: Do you think that the people sitting in this room are qualified to run your company?

CEO: (surprised) Of course! Every one of the executives present here has my full vote of confidence!

Me: Let us start with you then. What is your background?

CEO: Sales and marketing.

Me: Which implies you can’t be considered an expert in the areas of finance, accounting, payments, risk and IT, right? So, using your logic, how can you run the company if you are not an expert in all these areas?

CEO: But I have specialists in all those areas reporting to me and I rely on their expert opinions when making decisions …

Another field that is utilizing the latest developments in psychology is - surprising to many people - e-commerce. We all shop on the Internet for books, clothing, tools and electronics but very rarely do we realize how the site designers manage to manipulate and direct us using subtle but very powerful psychological tricks. Here are some of them:

• "Buy" and "Add To Cart" buttons - ever noticed how large and colorful they are? Do you really think it is just a design quirk of the user interface specialist? And yet it has been proven that color, size and even irregular shape have a proven, measurable impact on products added to cart, checkout initiation and checkout completion.

• Free Shipping vs. Savings - do you think that $10 in money saved is always better than $6.99? The conventional answer to that question is "yes", but a professor from Wharton School of Business found that consumers preferred free shipping worth $6.99 in savings over a $10 discount on the product. And smart e-commerce retailers take full advantage of this irrational behavior.

• Lump Sum vs. Distributed Payments - by the same token, when offered to buy a warranty for additional $15, most of the customers declined that offer. But guess what they did when they were offered to pay $2 per month for the next 12 months for the same warranty?

• Usage of "Will" - the e-commerce psychologists argue that the following statement "Shampoo X will calm itching and will reduce redness" is much inferior to "Shampoo X calms itching and reduces redness". Some peculiar processes in our brains forces us to believe the second type of statement way more than the first one.

As was mentioned earlier, this technique could probably be quite useful in software and product development, although it is possible to employ it on certain multidisciplinary projects as well.

Whenever I either teach my “Project Portfolio Management Masterclass” or consult on project portfolio management initiatives I like to surprise the senior executives with a seemingly innocent question:

Oh, by the way, do you consider your internal company resources to be free?

After the angry noise in the audience finally subsides, one of the executives – usually in a voice full of emotion – replies to me:

Of course not! Our employees are the main and the most valued asset at this organization!

Knowing that the trap is set and the victims are completely unaware as to what really awaits them, I ask the next innocuous question:

So, in that case, do you include the cost of internal resources when assessing the feasibility of your projects?

As a rule, about 90% of the time my question is greeted by a complete silence. The executives exchange glances attempting to comprehend the meaning of my question and finally answer something to the effect of,

“Uhm, no, not really … They are considered to be a fixed rather than a variable cost”

In order to analyze this problem, let us consider two scenarios. In the first one we have to choose between projects A and B. For simplicity let us assume that the only factor of importance in this case is the return on investment (ROI), one of the most uncomplicated financial formulas.

Project A should generate revenue of $1,000,000. The external (direct) cost of this project is $500,000 (e.g. purchase of materials and equipment).  In addition the company should expect to “invest” about 200 man-months of their internal resources, but since we are not considering the internal employee costs, the overall impact of this factor on the total project budget is zero (see Figure 1).

Project B is also expected to generate $1,000,000 in revenues, but the external cost is expected to be $750,000. Also, the human investment is estimated to be 5 man-months. But again, since the “internal employee” costs are ignored, the overall impact of this factor is also zero.

I remember one instance when I was teaching my “Project Management Masterclass” for the executive team of a North American port authority. The purpose of this class was to introduce this group of people to the core fundamentals of the project management science and convince them to seriously consider implementing this methodology at their organization.

This workshop has been highlighted by many interesting discussions and even heated arguments about the domain of project management, the value of planning and the role of the project manager. However the most interesting – at least in my humble opinion – exchange took place when I started describing the “dos” and “don’ts” of requirements gathering and analysis:

Me: When documenting requirements the project manager should always make sure that words like “fast”, “acceptable”, “efficient”, “flexible”, etc. do not appear in project management documentation.

COO: And why not?

Me: Well, you see, although these words are perfectly acceptable in “normal life”, they are considered to be ambiguous in the domain of project management …

COO: And?

Me: OK, let me share a very simple example with you. For instance, if the requirement states, “The car shall be fast”, it can later be misunderstood by the project stakeholders. Some of them will think 100 km/hour is fast enough, while others will insist on a speed of 300 km/hour. And yet, another group will ask for a speed of 500 km/hour. This will most likely create an unnecessary confusion and lead to conflict in the middle of the execution stage of the project.

COO: But we always use these words in our documents!

CEO: (interrupting the COO) Do you, guys, remember what happened on our recent “New Cruise Ship Terminal” project? We claimed in the project charter that we would build a state-of-the art facility and let that word slip into all other documents …

Me: And what happened?

Hi all,

Just wanted to let you know that I will be heading to Baku, Azerbaijan to continue my works on the troubled project recovery for one of the international companies located there. I should have full access to my e-mail and LinkedIn, so if you need to contact me, please drop me a note at info@thinktankconsulting.ca. Furthermore, my local number in Baku will be +994 51 728 9797. 

Cheers

Jamal

Hi all,

Just wanted to let you know that I will be teaching my 2-day “Project and Portfolio Management Masterclass” in London, UK in partnership with Marcus Evans on 13-14-Nov of this year. Here is a high-level outline of the class:

• How to Deliver Exceptional Project Results
• The Art of Estimation
• Are we Supposed to Negotiate on Projects?
• How to Define Project Scope?
• Customer Walkthroughs, Technical Inspections and Peer Reviews
• Why Should You Manage Scope and Customer Expectations?
• How to Maximise a Portfolio Value?
• How to Balance Your Portfolio?
• How to Link Portfolio to Strategy
• How to Implement Project Portfolio Management?

The detailed course outline can be accessed here (note you will be taken to the Marcus Evans website). For a detailed course brochure and registration information click here.

Let me know if you have any questions @ jmoustafaev@gmail.com

Cheers,

Jamal

Please leave your feedback in the “Add New Comment” section below. Also, feel free to share this article via Facebook, Twitter,LinkedIn or Google Plus by clicking the buttons at the top of the page.

Contact me if you have any questions regarding the article or our services at info@thinktankconsulting.ca

Dear friends,

In the course of the last couple of years I have been involved in a number of very large projects in my consulting capacity. One of the challenges we are encountering is that along with purely project management issues we have to address, we are also experiencing a lack of subject matter experts in the following domains:

• e-Government
• Banking
• Industrial parks
• Construction

Please note that we are not just looking for the people who merely have experience in the above mentioned areas, but rather for the industry thought leaders (e.g. LinkedIn Influencers, published authors, internationally acclaimed experts, etc.)

If you know anyone who fits that profile in any of the fields above, please do not hesitate contacting me at jmoustafaev@gmail.com. Also, you can leave a comment on the discussion thread on LinkedIn, Facebook, Twitter or Google+. And finally, please share and/or like this discussion, so that more people can see it.

Thanks,

Jamal