Way #1 - We Force Ourselves to Make Estimation Ranges Narrower

Ask anyone to estimate something. Anything, really. For example, ask them what is the distance between New York and Paris (5,839 km or 3,628 miles), and request that they provide you with a range that they are 90% confident in. Rather than saying, “Well, If you need a 90% confidence, then I would go with something like 5,000 km and 15,000 km”, they will provide you instead with very narrow ranges (say, 6,000 – 6,500 km) that are very close to the actual number but yet miss the target.  As a result, “90% confident” usually translates to “20-40% confident”.

Way #2 - We Suffer from the Optimism Bias

Humans constantly underestimate the complexity of the tasks assigned to them and chronically overestimate their ability to accomplish the said tasks (read more about this topic here and here).

Way #3 - We Fail to See the Connection Between Estimates and Probabilities

We have a very hard time understanding that as soon as someone asked us to estimate the duration of the project, we – whether we like it or not – have entered the realm of probabilities. Some of the questions that will affect the answer to the request above are:

• Will the customer want Feature X?
• Will the customer want the “Honda Civic” or “Ferrari” version of Feature X?
• If you implement the “Honda Civic” version of Feature X, will the customer later change his mind and demand the “Ferrari” version after all?
• How will Feature X be designed?
• How long will it take to debug and correct mistakes made in implementing Feature X?

Way #4 - We Tend to Think of Projects as One-Dimensional Entities

We tend to focus on just one dimension of the project. Usually it is either the time or money, e.g. “can you finish by next Friday?” or “my budget is capped at $10,000”.

What we neglect to see that every project has (at least) five dimensions:

Despite the fact that the role of project manager has been “institutionalized” by many respected international organizations including the Project Management Institute (PMI) and the International Project Management Association (IPMA) there are still a lot of confusion associated with this profession.

In my consulting career I have encountered the following perceptions about the role of the project manager:

Project manager is not really a profession. Every technical person working for our company should have the skills required to manage projects. I should have the freedom to point to an accountant (developer, marketing analyst, engineer, designer, etc.) and say, “Mary, I am assigning this project to you!”

Project manager is really an administrative worker, whose job is to collect project updates from various team members, send e-mails, take meeting notes and maintain the project schedule in the project management software.

Project manager is a very senior member of the executive team who is responsible for both tactical (i.e. delivery on time and on budget) and strategic (delivering value to the organization) success of the project.

Let us take a look at the real responsibilities of the project manager (see Table 1) and then try to refute the statements above.

Project manager is assigned at the initiation stage of the project. This is a point of time when the “go” decision on the project has already been made by the senior management, who deemed that the project in question was a good idea and would most likely deliver the proverbial value to the company. Therefore the project manager (unless she combines the role of the project champion and the project manager) is not expected to be responsible for the strategic success of the project. She may ask the questions about the project value if she has strategic knowledge about the domain and if she is very brave, but in general, the CEO of a large international bank should not expect the project manager to challenge him on the strategic value of the “Payments System Replacement” endeavor.

I remember once attending a lecture at the project management conference. The topic of the seminar was “One Week in the Life of the University CIO” and the presenter has shared very interesting details about the daily challenges of the “chief IT guy” at one of the largest universities in North America. He started his talk with a screenshot of his weekly calendar taken from his MS Outlook software and used it to describe the issues encountered and solutions his team was able to find to address the said problems.

At one point of time he directed our attention to a rectangle in his schedule and explained that in that particular case he had to conduct a final interview with one of the candidates for the project manager job at the university. The CIO added something to the effect of, “We got lucky because we were able to find a person with a lot of technical experience with Oracle Database 12. He actually worked on a couple of similar projects as a systems architect.” When asked by one of the participants about the candidate’s project management pedigree, the CIO quipped, “He did not have any specific project management training or experience per se, but he participated as a team member on a number of technical projects”.

This was not by far the first time when I have encountered this approach to hiring of the project managers. Furthermore, I dare to predict that most of the readers of this article have come across a similar attitude exhibited by their senior managers. The essence of this approach can be summed up in the following format:

When selecting a project manager for my next project I would rather hire a candidate with strong technical skills in the domain and weak project management skills, rather than someone with little technical knowledge, but excellent project management skills.

On a side note I have seen also several extreme versions of this tactic when the recruiters told me that the employer was specifically looking for a person who has experience with version 9 of the platform (apparently knowledge of versions 8 or 10 just wouldn’t do).

Let us for a second assume that this is the right approach and examine a couple of very plausible scenarios that may happen at your organization.

This is a seemingly simple question, at least, for a certified project manager. After all we all know that a project is an “endeavor that has a definite start and an end, undertaken to deliver a unique product a service”. Usually this definition is followed by a couple of illustrative examples:

• Creation of the first prototype of the Formula One car is a project since it does have a defined start, an end and produces a unique product.
• Mass production of, say, canned soup is not a project, since while it has a defined start it does not have a defined end. Also, thousands of cans can’t be considered a unique product since all of them are identical.

These examples unfortunately do not reflect the complexities that are usually encountered when deploying project management at various organizations. I remember a consulting engagement when we were working together with a focus group of the employees at a large government organization. One of the tasks on our agenda was to determine what would be considered a project by the company standards and thus require the application of the project management methodology. The following conversation took place between one of the employees and me:

Me: Project is an endeavor that has a definite start and an end undertaken to deliver a unique product a service.

Employee: Wait a second! So, according to this definition the act of sending an e-mail is a project, right? It has a defined start and an end and represents a unique product …

Me: Well, you can look at it this way …

Employee: Does this mean I have to write a project charter, requirements document and a project plan every time I intend to create an email?

I once had a conversation with a CEO of relatively recent start up. At the moment our conversation took place the company existed for about six or seven years. The CEO mentioned how successful his organization was and how they were discussing plans about expanding their product portfolio into new fields including taking on very large and complex government-sponsored projects.

When I asked him whether he was planning to beef up the project management skills of his employees he looked at me inquisitively and quipped,

“You really think we need to do that? We have accumulated a pool of very talented technical people and I am fairly confident they can take on any challenge that comes along”.

This is by far not the first time I hear a variation of this statement. Many executives continue to believe that the gift of their employees to successfully tackle smaller projects will automatically transfer into the ability to take on larger strategic endeavours.

Every company that manages to survive the start up stage eventually reaches the point when sound project management and portfolio management become strategic assets for the organization. There is practically no way to pinpoint this spot; personal experience tells me that the company usually enters the “danger zone” when it reaches one hundred employees or its revenues exceed $10 million (depending on the country).

Why does it happen? Let us look at the situation from a purely economic perspective. One of the first basic assumptions of every economic model is that people are greedy. Here is a simple example: if I offer you to choose between two piles of money and one of them has one thousand dollars and another one – five thousand, which one would you choose?

Executives and especially the company owners are no different from normal human beings from this point of view. Thus, when a CEO whose company has been involved with projects measuring in tens of thousands of dollars, gets an opportunity to obtain a million-dollar project contract, he usually does not hesitate about whether his company is ready to take on that challenge. As a matter of fact, such events are usually a cause for great celebrations at the organizations worldwide.