Project and Portfolio Management Experts

Jamal Moustafaev

Jamal is an author of two books dedicated to
project, portfolio and scope management:

Before you go any further, let us conduct a quick survey. Below you will find ten symptoms of a company that is in dire need of project management and/or project portfolio management. Go ahead, read through the list and count how many of these characteristics can be attributed to your organization:

  1. Unexpected issues and problems arise in the middle of projects
  2. Communications seem to be ad-hoc; too often important stakeholders are not informed about key decisions
  3. Project's requirements are never clearly defined
  4. Project managers and functional managers (department directors and managers) constantly fight over resources.
  5. Priorities of the projects initiated by the executives constantly change, resulting in quick resource reassignments.
  6. There is a chronic shortage of resources at the organization. Employees are constantly complaining about being overworked, while the managers insist that they must roll up their sleeves and work harder
  7. Projects are frequently late and/or over budget and/or do not deliver the full scope promised and the quality of the project product is low
  8. Even if the strategic idea is implemented, the company sometimes fails to achieve the expected improvement or fails to receive any value from the said project at all
  9. The strategic plan – even if the company has one - is presented as a list of projects, but the cause-effect logic tying those initiatives to the company’s mission, goals and the strategy is absent
  10. The list of company projects is not prioritized. Therefore it is assumed that all of these initiatives must be started and implemented more or less simultaneously

Did you count more than five symptoms present at your company? We can help! We offer project management, project portfolio management consulting and training services to help get your business back on track.

Please contact me directly via email at or by phone +1-778-995-4396.

I look forward to hearing from you.


Jamal Moustafaev, MBA, PMP

President & CEO

Thinktank Consulting, Inc.

Please share, your support is appreciated.

Article - Top 10 Questions to Ask When Conducting Project Document Walkthroughs


I would like to start this article with a very interesting statistic originating from the IT and software industry. Unfortunately, due to lack of reliable information from other sectors we have to rely on the data collected in the high-tech field and then construct generalized extrapolations to the rest of the world. So, without further ado, here is a very interesting statistic:

Forty-five percent (45%!) of project costs industry-wide is rework

Let’s ponder this number for a while … If we choose to believe in the power of extrapolation to one degree or another, it looks like by eliminating the amount of rework completely we can decrease all of our project budgets in half. Durations would probably fall by a significant number as well.

How can we minimize the amount of rework?

And the answer is: by conducting technical inspections and customer walkthroughs of all major project documents. The more documents get reviewed fairly early in the process, the less are the chances of missing scope items, unforeseen risks and hidden constraints.

Table 1 contains a list of questions that should be asked during such meetings.

Table 1


And what questions do you ask at your walkthroughs and inspections?

  1. We do not conduct project document walkthroughs
  2. We use the “ad hoc” approach. If a stakeholder sees an error, she just points to it
  3. We have a checklist of questions or potential problems to refer to

Please leave your feedback in the “Comments” section below.

Please share, your support is appreciated.

Article - Talent or Process: What Would You Choose?


Several variations of the following phrase have been attributed to a number of business leaders, politicians and, even scientists:

In order to be successful all you have to do is to hire a whole bunch of really talented people and abstain from interfering in their creative process.

I personally strongly disagree with this statement and want to share a study on the roots of project failures conducted by the Standish Group in 2006.

After, yet again, determining that our ability to deliver projects on time and on budget was seriously challenged, they went to the companies they were studying and basically asked the following question:

Our project delivery still sucks. Can you tell us why?

The results of that survey are presented in Table 1.

Table 1


A quick perusal of the table should not surprise any project management professional. Yes, lack of user involvement will kill any endeavor. Same goes for lack of detailed requirements document. Yes, projects where customers expect a delivery of a Ferrari for a price of a bicycle, will most likely go considerably over budget …

But an interesting thin happens if we attempt to highlight all of the factors related to processes, planning and systematic approach, thus separating them from the “human” factors (see Table 2).

Table 2


It turns out that 70% of project success is dependent on the underlying processes while only 30% can be attributed to the talents and industriousness of the team members!

To put it in perspective, let us imagine that we have two teams:

  • Team A consists of absolute technical geniuses, but does not follow any processes and does not have a project manager.
  • Team B is made up from “average” technical professionals, but follows proper processes and is lead by an experienced project manager

If you choose to believe the table above, it looks like Team B will beat team A 2 out of 3 times on any assignment we decide to allocate to them!

Please share, your support is appreciated.

Article - Top 10 Project Risks and What to Do About Them


Here is my favourite definition of risk:

Risk is a bad thing that can happen on your project, but you are not entirely sure it will

Below you will find a tables 1 and 2 with ten most common risks and ways to address them both early (highly recommended!) and late in the projects.

Table 1


Table 2


And what are your “favorite” project risks and what do you do about them? Please leave your comments below.

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 @

Please share, your support is appreciated.

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?

Please share, your support is appreciated.

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


  • 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
Please share, your support is appreciated.

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


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?

Please share, your support is appreciated.

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.

Please share, your support is appreciated.

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


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


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:

Please share, your support is appreciated.

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


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”

Please share, your support is appreciated.