Smartcuts to mitigate 3 common fallacies/biases in Program Management

I recently started learning more about good decision making and read Daniel Kahneman’s famous “Thinking Fast and Slow” book. It is a great read and led me to research more about fallacies and biases. It is very surprising to see the number of fallacies and biases that cloud our decision making. Some fallacies impact us more than others. In this blog, I am going to talk about 3 most common fallacies that we encounter in program/project management and smartcuts (smarter way of doing things) to mitigate them. While it is not possible to eliminate all biases/fallacies, being cognizant of them and recognizing them will guide us in making better decisions.

Here are the definitions of biases and fallacies from “Thinking Fast and Slow”:

“To be a good diagnostician, a physician needs to acquire a large set of labels for diseases, each of which binds an idea of the illness and its symptoms… Learning medicine consists in part of learning the language of medicine. A deeper understanding of judgments and choices also requires a richer vocabulary than is available in everyday language. Systematic errors are known as biases, and they recur predictably in particular circumstances”.

“The word fallacy is used, in general, when people fail to apply a logical rule that is obviously relevant”.

Summary of the 3 common fallacies/biases

Planning fallacy: Tendency to underestimate the time, costs, and risks of future actions and at the same time overestimate the benefits of the same actions.

Sunk cost fallacy: We demonstrate “a greater tendency to continue an endeavor once an investment in money, effort, or time has been made”.

Status quo bias: We stick with the option we are given even though the alternatives might be better, because it is the status quo.

Planning fallacy

Tendency to underestimate the time, costs, and risks of future actions and at the same time overestimate the benefits of the same actions.

Why does this happen?

Few biases that cause this fallacy:

1. Overconfidence bias: A person’s subjective confidence in his or her judgments is reliably greater than the objective accuracy of those judgments, especially when confidence is relatively high. One manifestation of the overconfidence effect is the tendency to overestimate one’s standing on a dimension of judgment or performance.
2. Optimism bias: Causes someone to believe that they themselves are less likely to experience a negative event.
3. Illusion of control: Tendency for people to overestimate their ability to control events.
4. Conjunctive event bias / conjunction fallacy: We overestimate the likelihood that a number of events will go as planned.

How to counteract planning fallacy?

As PMs/TPMs it is one of our main responsibility to provide realistic estimates. Some projects have leeway in their deadlines, and some do not. Depending on how much flexibility we have in terms of the dates, here are some smartcuts to counteract this fallacy to get better estimates:

1. Pre-mortem: We should think of what could go wrong, work backwards and plan for those scenarios.
2. Chunking: Break down the project into as small tasks as we can.
3. Use consensus-based estimation techniques: We can use techniques like Planning Poker which mixes the virtues of individual decision making and social learning. Planning poker is used by many agile teams and free tools like pointing poker can be configured to use any numbering system. However, it is important to remember that it is the conversation and convergence to agreement that matters more in consensus-based techniques. If it is just one person doing the estimate, they might overestimate their ability to get the task done and might not seek additional information as they do not know they need it. They would also be clouded with optimism, over-confidence, and illusion of control biases. Using consensus-based estimates would reduce the impact of these biases. While the consensus-based estimates reduce cognitive biases to a large extent, it is time consuming. To strike a balance between getting good estimates vs. time needed to get the estimates, we can use this technique only for the features that are complex or projects where we do not have much leeway in the dates.
4. Add buffer: This is a complex topic and depends on a lot of factors – type of project, whether there is a need to have a definite deadline, complexity, dependencies etc. Simplistically, if we have been working with the team and have a history of how much the estimates are off by, we can plan to add that much buffer. If it is a new team, and we do not have any idea, we can look for projects that were similar and gauge the buffer.

Sunk cost fallacy

People demonstrate “a greater tendency to continue an endeavor once an investment in money, effort, or time has been made”. This is the sunk cost fallacy, and such behavior may be described as “throwing good money after bad”. 

Why does this happen?

1. Commitment bias: Also known as the escalation of commitment, describes our tendency to remain committed to our past behaviors, particularly those exhibited publicly, even if they do not have desirable outcomes. We try to convince ourselves and others that we are rational decision-makers by maintaining consistency in our actions, as well as by defending our decisions to the people around us.
2. Loss Aversion: This is the tendency to prefer avoiding losses to acquiring equivalent gains. Loss aversion was first identified by Amos Tversky and Daniel Kahneman.  Loss is felt more acutely than gain of the same size. Example losing $20 is worse than not gaining $20.

A couple of examples of where sunk cost fallacy would manifest in program management:

1. Imagine we sign a contract with a vendor to deliver a project that is supposed to be completed in 6 months. 3 months into the project we realize that the vendor is not going to be able to deliver and that there would be significant delays. Since we already have relationship with the vendor and have invested time and money, we decide to continue with this vendor.
2. Imagine we invested $100K on a project that is estimated to bring in $200K in savings. Halfway into the project we realize that we have spent $75K and the savings projections drop to $100K. Since we already spent $75K and we are halfway into it we decide to continue with the project. Calling off this project would be considered as a project failure.

How to counteract sunk cost fallacy?

1. Be cognizant that this is a fallacy. We should not just think about the time/money we have already spent. Instead we should think of how much additional time/money is needed and if continuing the project is going to be a worthwhile investment.
2. Companies can help employees overcome loss aversion by putting greater values on gains and less penalties for losses. Set rewards associated with gains to be at least twice as likely as the penalty for loss. While this is something at company level and might not be something in our sphere of influence, we can influence it at a program/project level when framing wins/losses. Ex: Instead of framing it as “We were over budget by 10%” frame it as “We were within +10% of our initial estimates”.
3. Avoid the stigma that stopping a project is a failure. Instead frame it as a lesson learned and incentivize people for making such decisions in the projects/programs we manage.
4. Consider opportunity costs – By sticking to the original plan, think of all the projects that we are giving up.

Status quo bias

We stick with the option we are given even though the alternatives might be better, because it is the status quo.

Why does this happen?

1. Appeal to tradition: We have always done this way and so this is the right thing to do. This fallacy fails to consider new information.
2. Sunk cost fallacy: As mentioned above, due to sunk cost fallacy we might stick to status quo.
3. Loss aversion: Again, as mentioned above, loss aversion is our tendency to avoid losses and prevents us from changing from status quo due to a fear of failure.

A few examples where we would see this:

1. We propose moving teams to Agile methodology and their response is “Waterfall works fine for us. Why should we change”?
2. We propose using a Project Management tool like MS Projects, Jira etc instead of spreadsheets and there is resistance from the teams since they are used to working with spreadsheets.

How to counteract status quo bias?

Reflecting on all the times I have proposed a changed, the initial response has often been “Why should we change?”  “It is cognitive load to use multiple tools”, “Teams are used to using spreadsheets” etc. I now understand that their response is partly due to status quo bias.  Here are a few smartcuts to counteract status quo bias:

1. When we propose any change, we should be be very clear and intentional about why we are proposing a change. Explain the problem statement we are trying to solve. Detail the pros/cons of status quo vs. the change.
2. If we/teams think “We have already spent so much time using this tool/process. Let us not change”. Make sure sunk cost fallacy is not in play.
3. Evaluate the opportunity cost of making the change vs. status quo.

While this blog post is geared towards TPMs/PMs, other roles like leads, managers etc. can also benefit from knowing about these fallacies/biases and ways to counteract them.