Overconfidence in Project Management

Most successful professionals have a great deal of confidence. This is particularly true of project managers.  They have climbed the technical ladder to reach the project manager position and a few successes may have elevated them in the eyes of management above the other project managers.  This can cause overconfidence which is a situation ripe for disaster. A project manager who is overconfident in his/her project strategy, technical solutions, time and cost estimates is dangerous. That overconfidence leads to assuming too many risks at too high a level. A humble project manager is a much better bet for project success. The humble PM doesn’t decide that risk management is unnecessary because he’s a great problem solver and firefighter. That’s just foolish.

Consequences of Overconfidence in Project Management

Overconfidence in project management has lots of consequences some good, some bad. Overconfidence affects a project and their managers in lots of ways:
1. When PMs make commitments on completion dates
2. When team members make estimates for their tasks
3. When engineers commit to making a solution work.
What do I mean when I say overconfidence? Project Manager Skills Main Page

A few days ago, I was having a conversation with a friend who studied Overconfidencepsychology. We touched on overconfidence, an especially interesting topic regarding common human behavior and decision making. It appears that there is scientific consensus documented in hundreds of research studies. They call it the better-than-average effect. The majority of us humans are much more likely to overestimate our level of skills, or be overly optimistic regarding our future, rather than underestimate.
This reminded me of common mistakes in project management. Mistakes mainly related to wrong estimation, overly optimistic assumptions and neglected risk management. As I do not have the research or hard quantitative data, I can share my personal experiences and opinion on how overconfidence can significantly lower the probability of success for project. To be entirely fair, sometimes it can have a positive result in motivating the team toward an above average performance.

Examples of Overconfidence in Project Management

Here are two examples if overconfidence in project management that I will touch on.
The first is a project responsible to deliver a system for managing a lending process. It had an original estimation to finish in 9 months. Instead, it finished after 2 years. Clearly, in the eyes of the sponsor, stakeholders and steering committee, it was labeled a disaster. The worst part was that every time the team reported a status they asked only for 1 more month deadline extension. This presented, in their view, a realistic plan to finalize the scope. They worked an average of 12 hours a day, but the end result was a disappointment. The project for the next years became the benchmark of what could be done wrong. In another country of the same bank with almost the same project scope, they had an estimation of 3 years. They finished 2 months ahead of time and were praised for the achievement.

The second example is a project related to credit risk. The benchmark for projects with a similar scope in other counties was 1.5 years. The local project pulled it together in 7 months. How? Practically without sleeping and keen will to stay to their commitment. This is again an example of overconfidence, yet the team this time succeeded. The project was praised and it became one of their strong assets for promotions and their CV.
Even though, I believe that the more generic effect of overconfidence is the first example, the second is a possible scenario as well. A team can be energized, especially if they are the source of the estimations (bottom-up), to achieve  against-the-odds results.

What can a project manager do to manage these phenomena? First it is important to know that people are subject to unbalanced decisions, or estimations, usually on the upper side. It can be addressed as one part of risk management plan. When applicable, it helps to have industry standards for the resources and duration needed for specific tasks. An example are the benchmarks regarding software development productivity and duration. These benchmarks then compare to the bottom-up estimates. It is normal to expect some degree of deviation, yet if the difference is more than 30%, it is worth digging and understanding a bit deeper.

Apart from the risks it brings, overconfidence may as well be a tool used to comply with external constrains, which require an above-the-average performance. A committed team is more motivated to stay to the commitment. If committed, even when the team is required to deliver above its normal productivity levels, it is more likely to do so.
No cookbook and easy way exists to deal with overconfidence; it is rooted in our being. Yet I believe that acknowledging it and putting triggers and actions in place to mitigate and/or make use of it may became the difference between success and failure.

If you are interested, you can check out an interesting article on the topic: The Overconfidence Problem in Forecasting, NY Times, author: RICHARD H. THALER . Some other researchers are Camerer and Lovallo 1999, Hoelzl and Rustichini 2005, Koszegi 2006, Chuang and Lee 2006.