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?

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

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

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:

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

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”

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

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?

Very proud to have participated on this project as a project management consultant!

Background

Shah Deniz (The King of the Sea) gas field is the largest natural gas field in Azerbaijan. It is situated in the South Caspian Sea, off the coast of Azerbaijan, approximately 70 kilometres (43 mi) southeast of Baku, at a depth of 600 metres (2,000 ft). The field covers approximately 860 square kilometres (330 sq mi). The Shah Deniz gas and condensate field was discovered in 1999. Stretching out over 140 square kilometres, the reservoir is similar in size and shape to Manhattan Island.

Shah Deniz 1

Stage One development of the Shah Deniz gas field started production in 2006, with a capacity of 9bcma of gas and roughly 55,000 daily barrels of condensate. The capital expenditure on Shah Deniz 1 to date is estimated to be $6bn. As of 2013, the field has produced 47.3 billion standard cubic metres (1,671 billion standard cubic feet) of gas and 99.5 million barrels of condensate.

Shah Deniz 2

Shah Deniz-2 discussions started in 2008 with the main discussion topic being the selection of transportation routes for additional gas volumes. Five-year-long intense negotiations finalized with signing of Final Investment Decision (FID) on 17 December 2013 in Baku, Azerbaijan.

Nine companies agreed to sign a gas sales agreement (GSA) with the consortium:

• Axpo Trading AG
• Bulgargaz EAD (Bulgaria)
• DEPA Public Gas Corporation of Greece S.A. (Greece)
• Enel Trade SpA (Italy)
• E.ON Global Commodities SE (Germany)
• Gas Natural Aprovisionamientos SDG SA (Spain)
• GDF SUEZ S.A. (France)
• Hera Trading srl (Italy)
• Shell Energy Europe Limited (UK)

Out of total 10 bcm intended for Europe, 1 bcm will go to Bulgaria and Greece and the rest will go to buyers in other countries, mainly Italy.

Some interesting facts:

On Target        

• 89% of projects at high-performing organizations meet original goals and business intent
• 34% of projects at low-performing organizations meet original goals and business intent

Building Blocks

• 71% of projects meet original goals and business intent at organizations that recognize the importance of project management
• Unfortunately only 38% of organizations place a high priority on creating a project management culture

Down the Drain

• US$122 million lost for every US$1 billion invested in projects due to poor performance
• That is a 12% increase from 2015

PMO

• Only 49% of organizations have EPMO
• Of those only 44% are highly aligned with their company strategies (22% of all organizations)
  • They complete 27% more projects successfully
  • 42% fewer projects have scope creep

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

This is my 100^th post on LinkedIn, so to celebrate this event I decided to do something funny and light-hearted, but yet still relevant to the domain of project  management. The problem is that by the time I became a father, I have already been a fairly established PM professional, so I couldn't help but to look at this fatherhood thing through the proverbial “project management glasses”.

So, without further ado, here are the top 10 things I learned in the past four years:

Lesson #1 – Scope Creep (#projectscopemanagement)

No matter how much time you spend eliciting, analyzing and baselining your road-trip requirements, you scope of work can be instantaneously shattered by your rascal meditatively grabbing his behind followed by a simple, “Dad, I have to go. Number two. NOW!”

Lesson #2 – Buffer Time (#projecttimemanagement)

Remember, buffer time added to your estimates is your friend! The rule of thumb is fairly simple: however long it took you to accomplish the task before you had your kid, multiply that number by four (e.g. 15 minutes = 1 hour)

Lesson #3 – Critical Path Will Change All the Time (#projecttimemanagement)

Let us assume that you are planning two parallel tasks:

• Task A – Comb your child’s hair (performed by you) and
• Task B – Prepare a sandwich for the picnic in the park (your spouse)

You estimate:

• Task A – 15 seconds
• Task B – 7-10 minutes

Therefore task B is on the critical path, while task A has at least 6 minutes and 45 seconds of slack, right? Wrong!!! As soon as your fearless “Captain America” sees you with a hair brush in your hands, he throws a tantrum so bad, it causes his mother to run up the stairs screaming, “WHAT. ARE. YOU. DOING. TO HIM?”

As a result you have to join your efforts, thus making tasks A and B sequential rather than parallel.

While project management has been almost fully embraced by the private sector in most of the developed (and certain parts of the developing) world, the government sector still remains a curious wonderland where large projects get initiated and "executed" without any professional involvement of project managers. And yes, I am omitting words like "planned", "monitored" and "controlled" on purpose!

I remember one interesting conversation that took place with an employee of a large government agency, whose management continued to claim that "project management was a waste of time" and that "in any case, we outsource the entire project to a construction company, so why should we bother?"

Me: So tell me, how do you run projects here?

E: Well, at some point of time someone up there (points to the ceiling) decides to build a new port facility ...

Me: And then?

E: The Steering Committee obtains the money based on some very arbitrary estimate and announces to all our departments that the project will be starting on January 1. The Real Estate department is the first on the scene since they have to acquire the land for the future development. They take care of that and pass the files to the Legal department ...

Me: And what happens then?

E: The head of the Legal department is very surprised to see these documents, but the representative of the Real Estate team exclaims, "Remember we had a discussion about this project a couple of months ago? Well, here you go! My job here is done". The head of the Legal team suddenly remembers the now-vague conversation that took place at the Steering Committee meeting, curses and assigns the case to one of his overworked lawyers.

Me: OK, but that is not the end of the story ...

E: Oh no, you ain't heard nothing yet! Begrudgingly the Legal team prepares all of the documents required and one day surprises the next victim - the Planning department. Keep in mind that by that time the historical Steering Committee meeting is three or four months behind us. So, the Planning department has already lost any recollection about that project.

Me: And how do they react to this?