Article - How to Explain Why “Estimation” Equals “Uncertainty”?

 

When dealing with stakeholders who do not have much experience in project management we inevitably encounter a situation where we have to provide “quick” estimates early in the project life cycle. The science of project management encourages us to use plus-minus estimates, ranges and coarse estimates (see more on the topic: Five Proper Ways to Present Project Estimates).

However, usually the stakeholders are very keen to hear very precise numbers like “the project duration is going to be 9 months and 3 days” or “the total budget is going to be $245,433”.

So, how do you explain to your customers that as soon as you started generating project estimates (especially the early ones), you have entered the domain of uncertainty?

I usually like to demonstrate the principle of uncertainty by picking a simple example completely unrelated to the project at hand and dissect it piece by piece right in front of their eyes.

Will the customer want Feature X?

In other words, will the customer decide to add Feature X to the dozens (hundreds, thousands) of other features already added to the project scope?

Example: Will the customer decide to add the “Landscaping” feature to the “Build a New Home” project?

Will the customer want the “Honda Civic” or “Ferrari” version of Feature X?

Will the customer prefer to go with a cheaper and simpler version of the chosen feature, or opt for a luxury kind?

Example: Will the customer choose to plant ten Eastern White Pines ($50/tree) or fifty Little Gem Magnolias ($500/tree)?

If you implement the “Honda Civic” version of Feature X, will the customer later change his mind and demand the “Ferrari” version after all?

Example: I am sure it never happened on your projects, but is there a chance that the customer who initially decided to go with ten Eastern White Pines, will change her mind and opt for fifty Little Gem Magnolias?

Article - Five Proper Ways to Present Project Estimates

 

How often have you been in a situation when your manager (customer, stakeholder, etc.) taps you on the shoulder and says something to the effect of:

Hey, Bob, I have this little project for you. Here is what I need (proceeds to describe scope at a very high level). How long do you think it would take your team to deliver this? Can you provide me with your estimate by the end of the day (week)?

Every project manager is aware of the fact that as soon as we said “project estimate”, we, whether we like it or not, said “uncertainty”. So here is a million-dollar question:

How to provide quick estimates when very little is known about the final product?

Option 1: Plus-Minus Qualifiers

Example: This project should take six plus/minus two months

Duration = 6 months ± 2 months

Option 2: Ranges

Example: This project should take anywhere between four and eight months

Duration = 4 months – 8 months

Option 3: Cases

Example:

  • Best case – 4 months
  • Most likely – 6 months
  • Worst case – 8 months

Option 4: Coarse Dates and Time Periods

Example: “3 Quarters” instead of “9 months” (or 180 days)

Duration = 3 Quarters

Option 5: Confidence Factors

Example: “We are 90% sure that the project will be done in between 90 and 120 days”

And how do you present your project estimates? Please leave your comments below.

  1. Single number
  2. Plus-Minus Qualifiers
  3. Ranges
  4. Cases
  5. Coarse Dates and Time Periods
  6. Confidence Factors

Article - Why do Projects Really Go Over the Budget?

 

I recently came across the “Olympic Proportions: Cost and Cost Overrun at the Olympics 1960-2012” article published by Bent Flyvbjerg in 2012. One of the figures that really got my attention was a table describing the actual costs and budget overruns of the Olympic Games between 1968 and 2012 (see Table 1).

Table 1

Olympics.PNG

Inspection of this table and the numbers got me thinking once more about our inability to learn from our mistakes and budget our projects properly. Then I remembered and article I have written some time ago titled “Project Underestimation: Mass Delusion or the Machiavelli Factor?”

There are currently three theories attempting to explain our helplessness when it comes to accurate project estimation. In a nutshell, here are explanations by three different schools of thought:

  1. The Standard Economic Theory Explanation - 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.
  2. The "Mass Delusion" Explanation - Modern business decision making is seriously flawed because of the delusional optimism (optimism bias) that forces people to overestimate the benefits and underestimate the costs of future projects.
  3. The Machiavelli Factor Explanation – executives and politicians are deliberately cooking the books in order to make the project proposals look more attractive. In addition, executives are rewarded with heavy incentives for rosy forecasts and face very minor penalties when their predictions proved to be wrong.

I personally tend to lean towards the blend of theories #2 and #3. In my experience the following happens:

  • Projects in the private sector - 50% optimism bias and 50% Machiavelli factor
  • Projects in the government sector – 25% optimism bias and 75% Machiavelli factor

So, having voiced my opinion on the topic, what is yours?

Article - Should Executives Get Involved in Project Portfolio Management?

 

Another seemingly simple but frequently encountered illusion is that the project portfolio management process can somehow go ahead without the direct involvement of the executive management. Very frequently when teaching my public project portfolio management masterclass I am engaged in the following conversation with at least one of my "students":

 

S: Hi, my name is Pascal, and I am a newly-appointed Director of Portfolio Management at company X. My goals today are to learn as much as possible about practical PPM and implement it once I get back to our headquarters.

Me: Will your executive management participate in the process?

S: No, unfortunately not. They are very busy people, you know ... But they assured me I would have their full support in this undertaking!

Me: So, who is going to create the scoring matrix, balance and strategic alignment models?

S: Hopefully I will do that once I am done with the course.

Me: Understood. Let me paint the following picture for you, and you can tell me at the end whether this sounds as a plausible scenario. You create the scoring matrix, balance and strategic alignment models. At one point of time you are approached by your company's CEO or Senior VP who asks you to add this "very important project" to the organizational portfolio and initiate it as soon as possible. However upon analyzing the proposal, you come back to you boss and tell her that the project will not be going ahead because it scored only five out of the possible 50 points in the prioritization model. What do you think her response will be?

S: She will ask me who created the model!

Me: And once you reply that the model was your creation, what is the likely response?

S: She will probably say something to the effect of that the creation of such models wasn't really in my domain of responsibilities.

Case Study - What Went Wrong with the Most Expensive Warship?

Introduction

The project to deliver the most expensive warship in the world is $2.3 billion over the budget and 2 years (and counting) late. The US Navy’s newest $13 billion aircraft carrier is still not ready for combat because of mechanical delays that have already put it two years behind schedule, according to the Pentagon’s top weapons tester.

The USS Gerald R. Ford (see Figure 1 for more info) was supposed to be ready by September 2016, but Michael Gilmore, the Defense Department’s director of operational test and evaluation, said in a June 28 memo that the warship had ongoing launch and recovery problems.

Figure 1

USS Gerald Ford_0.PNG

The construction of the ship started in November 13, 2009 and is still ongoing. Click on the video below to watch the time lapse.

Video - USS Gerald Ford Construction Timelapse

 

The Problems

Table 1

USS-gerald-ford-table_0.PNG

The Root Causes

Let us try to analyze the root causes first.

"Unrealistic business cases, poor cost estimates, new systems rushed to production, concurrent design and construction, and problems testing systems to demonstrate promised capability"

Chairman of the Senate Armed Services Committee Senator John McCain

However the some officials indicated that missed deadline can be attributed to the decisions made when the Pentagon committed to building the advanced ship in 2008.

"The decision to proceed with these three systems was made many years ago, prior to their maturation, when transformational approaches to acquisition were a DOD policy,"

Mark Wright, a Defense Department spokesman.

Let us try to make some sense out of the information presented above:

Article - How to Prioritize Project Features and Explain the Process to the Stakeholders

 

When the Requirements Specifications is complete, the project manager (or the business analyst) must inspect the document with all the stakeholders in order to (along with other very important things) prioritize all of the project features and/or requirements.

Project features have to be prioritized for the following reasons:

  • Prioritization eliminates unnecessary, frivolous scope items added to the project scope
  • It decreases the project scope thus potentially saving time, money and resources
  • It allows you to focus is on the truly important items

However, the prioritization exercise could become a very painful process, especially when the project manager is working with the stakeholders who are not very familiar with the core principles of project management. As a result they frequently tend to counter every prioritization request with phrases like:

Everything in this document is equally important!

Statements like “this is a low-priority feature” are not culturally accepted at our company

We have a “yes, we can” attitude at this firm!

And my favorite:

Well, you ARE a professional project manager. Can’t you deliver all of these items on a tiny budget and a ridiculously aggressive timeline?

To address this problem I usually start my prioritization exercises by showing the stakeholders the following table (see Table 1):

Table 1

priorities-table_0.PNG

Usually the dialogue goes something like this:

Me: OK, now to the “Rear-view Camera” feature … How important is it?

Stakeholder: Very important! Definitely a “Must-Have” item!

Me: But if we throw it out, does it mean we have to abandon the entire project?

Stakeholder: No, not really … How about be assign it a “Should Have” status then?

Me: Is it of same importance as the “Passenger Seat” feature? In other words, if it came to deciding whether to cut the “Passenger Seat” feature or the “Rear-view Camera” feature, would you think for too long?

Stakeholder (with an audible groan): OK then, let’s go with “Nice-to-Have”

Article - What is the Most Important Project Document?

 

If you ask a person studying for a PMP exam, what is the most important area in the domain of project management, the correct answer is "communications". After all it has been documented that on average project manager spends up to 90% of his/her time performing communication activities such as conducting meetings, writing project documents and potentially eliciting requirements via one-on-one interviews.

While I wholeheartedly agree with this notion, I tend to think that the domain of communications is a bit too general to be designated as "the most important thing in project management". I would like to offer to look at this issue from a slightly different perspective:

If you were allowed to write just one project document on your project, which one would you choose?

My answer to this question is the “Requirements Specifications Document”. While some of you may vehemently disagree with me and mention Project Charter and Project Plan. But let us just think about this for a while. The domain of project management is divided into ten knowledge areas (see Figure 1)

Figure 1

project-management-knowledge-areas.PNG

Let us examine the impact of scope on other knowledge areas:

Time Management: If you don't have a detailed requirements document can you develop a work breakdown structure and create a network diagram (project schedule)?

Example: The project can take way longer if the customer decides to add a “swimming pool” feature to his villa design.

Budget Management: Can you create a detailed project budget - including human resources required and expenses on equipment and materials - until you have a baselined requirements document?

Example: Will the customer choose a $5-per-square-foot type of flooring or a $150-per-square-foot one?

Quality Management: Can you define the acceptable quality levels and tolerances until you know all of features of the product?

Infographic - Project Portfolio Management Model - Electric Utility Service Provider

 

Infographic - PPM Model - Electric Utility Service Provider.png

About the Author

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East.  Read Jamal’s Blog @ www.thinktankconsulting.ca

Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.

Infographic - Project Portfolio Management Model - Electric Transmission Operator

 

Infographic-PPM-Model-Electric-Transmission-Operator.png

About the Author

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East.  Read Jamal’s Blog @ www.thinktankconsulting.ca

Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.