project management

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?

Introduction

In my previous blog posting "Seven Questions to Ask When Dealing with a Troubled Project" we examined the questions the project manager should ask when handed a troubled project. Let us now take a look at the possible actions one may initiate based on the answers received.

Answer #1 - This Project is Failing Due to a Poor Portfolio Management Decision

Actions you may consider:

• Cancel this project.
• Go back to the drawing board to change the project scope, timeline, budget, resources or timing to better fit company strategy, required project balance or to improve its value.

Answer #2 - We are Failing with the Project Scope

Actions you should probably take:

• Initiate proper requirements elicitation, analysis and documentation procedure. This action should be undertaken by the individuals specifically trained in requirements engineering.
• Ensure that the requirements document is written at a consistent and appropriate level of detail, provides an adequate basis for design and covers all possible  alternatives and exceptions.
• Get rid of all the TBDs and ambiguous words in the requirements specifications document.
• Conduct walkthroughs, inspections and peer reviews with customers, technical team and an experienced project manager.

Don't forget to ask the following questions in order to renegotiate the project scope:

Introduction

I am frequently being asked the following question in my consulting and training and training engagements:

We have a troubled project at our organization. What is the starting point when dealing with such ventures? What questions do we have to seek the answers for in order to rectify the situation?

Question #1: Why is this project failing?

In my opinion this is the most important question to ask. Before we move further in his analysis of the failed or troubled project we need to establish whether the failure should be attributed to the project portfolio management or project management root causes.

If we establish that - even if finished on-time and on-budget - the project would most likely not add any value to the organization (domain of portfolio management), why should we waste time and resources on putting it back on the rails? In other words, if determined that the project was a bad idea to begin with (e.g. construction of a new airport that no airline intended to use )we should probably either cancel it outright or go back to the drawing board and, if possible, change the design of the final product.

Question #2: Where did we fail on the project portfolio management side of things?

If we managed to establish that the failure was on the project portfolio management end of the spectrum, then the next step should be dedicated to find out where exactly our shortcomings were. Depending on the type of the organization the answers to this question could vary quite considerably.

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.

Hi all,

I have had a chance to chat with Cornelius Fichtner of Project Management Podcast. We were discussing my new book "Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects" and in the course of the interview I was asked to answer the following questions:

1. What is project scope management?
2. What is the state of project scope management nowadays?
3. Why did you decide to write a book about it?
4. What makes this book unique?
5. Who is this book for?
6. What are the main processes in the project scope management?
7. What is the state of project scope management in the IT and software development industries?
8. What is the state of project scope management in construction, product development, engineering?
9. What is your perspective on project scope management in multidisciplinary or enterprise projects?
10. How does project management play into this?

The interview has already been downloaded more than 27,000 times from the PM Podcast website.. Hope you enjoy it as well.

About the Author

Returning back to Vancouver, BC after a 2-month engagement on two US$ 20 million Oil & Gas projects in Baku, Azerbaijan.

Hoping to be back soon ...

“If you don’t know where you are going,

you’ll probably end upsome place else.”

Yogi Berra

Tip #1: Understand the Importance of Requirements

Five out of the top eight reasons why projects fail are related to scope definition, according to the Standish Group. These include:

• Incomplete requirements
• Lack of user involvement
• Unrealistic customer expectations
• Changing requirements and specifications
• Customers no longer needing the features provided

Further analysis of causes of “bad” requirements yielded the following results (see Table 1).

Table 1

 A study conducted by Barry Boehm (one of the leading thinkers in the field of software development) involved an analysis of 63 software development projects in companies such as  IBM, GTE and TRW and determined the relative costs of fixing an error at various stages of the project.  Results from the study, demonstrate a phenomenal increase in the cost of a mistake from one dollar at the Initiation stage of the project to $40-$1,000 range at the Closeout (see Figure 1).

Figure 1

 While this information is based on the software development industry, this trend, to a certain extent, holds true for most other industries.

The scope problem is not rooted in our inability to come up with detailed blueprints, bills of materials or design and architecture documents. The predicament lies in the initial stages of the projects, when we need to elicit a high-level initial set of customer problems, issues and needs, and propose potential solutions.

Negotiation is a dialogue intended to produce an agreement

upon courses of action, not only by actively selling

your position but also by focusing on the other side's

interests, needs, priorities, constraints and perspective.

Tip #1: Use Investigative Negotiations

 When negotiating on projects, both parties involved default to the discussion of their respective demands or try to state their positions in the clearest ways possible. Dig into your own memories and try to see if you have ever heard the following statements from your clients or managers:

• “This project must be delivered by October 30^th of this year”.
• “You are limited to ten resources on this project”.

Project managers are also prone to uttering statements like:

• “We can’t hit this deadline even if we work sixteen hours a day”.
• “If I don’t get the resources I asked for, we are not going to deliver this project”.

The problem with this approach is that we focus on the positions or demands of both parties rather than trying to understand their underlying interests and reasons. We assume that the key to a successful negotiation lies in understanding what the counterpart actually wants. While this is true, it is not the end of the process but rather a beginning. Focusing on what their customers want frequently distracts even the most experienced project managers from why they want it in the first place.

Therefore, questions like "why?" and "why not?" become the project manager's best friends during any negotiation process.

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:

Hi all,

I have had a chance to chat with Cornelius Fichtner of Project Management Podcast. We were discussing my new book "Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects" and in the course of the interview I was asked to answer the following questions:

1. What is project scope management?
2. What is the state of project scope management nowadays?
3. Why did you decide to write a book about it?
4. What makes this book unique?
5. Who is this book for?
6. What are the main processes in the project scope management?
7. What is the state of project scope management in the IT and software development industries?
8. What is the state of project scope management in construction, product development, engineering?
9. What is your perspective on project scope management in multidisciplinary or enterprise projects?
10. How does project management play into this?

I have already received some very positive feedback regarding the interview. Hope you enjoy it as well.

About the Author