Article Overview
It is time to review how our project objectives and team members are damaged by things that are not readily visible.
Table of Contents
- Clustering Illusion
- Confirmation Bias
- Anchoring Bias
- Sunk Cost Bias
- Survivor Bias
- Dunning – Kruger Effect
- Summary
These are actual self-inflicted and we are not aware of the damage that has been done, the impact of this bias may come to roost at some future date, or we may get lucky, but not really. This lucky event will be perceived as a success due to knowledge and actions taken, that our thinking was clear, and our actions well thought through and that is why we (the project) were successful. This may, in fact, not be even close to the truth.
A cognitive bias is a systematic error in thinking that impacts one's choices and judgments. The concept of cognitive bias was first proposed by Amos Tversky and Daniel Kahneman in a 1974 article in Science. Since then, researchers have identified and studied numerous types of cognitive biases. These biases influence our perception of the world and can lead us to poor decision-making. 1
Our brains are wired to find patterns. The problem is that we often see patterns where no pattern exists. This was helpful when we were in the wild, it would be better to think there is a predator nearby when we “see” things and take appropriate action. If we did not, we would end up being some predator’s meal. However, pattern detection often requires more than a cavalier look. To truly find a pattern, often requires some measure of analysis, often statistical. Many of the project team members may not understand the implications of small sample size, too small to mathematically discern a pattern. For example, two or three points on a straight line do not mean the rest of the data will be a continuation of the line.
This has the possibility of impacting our project management endeavors in many ways that metrics that are collected and perhaps interpreted prematurely.
Confirmation bias happens when we actively seek evidence to support what we already believe and find it, as well as interpreting evidence it in the light of what we believe. Looking for evidence to support what we already believe is not the path to understanding or the truth about what can happen. From a project perspective, this type of bias will impact our planning, execution and monitor and control actions within the project.
For example, we will select metrics based upon this confirmation bias, not really informing us well. The problem with looking for evidence that proves what we believe to be true has some downsides. Having evidence that we are correct, does not necessarily mean we are correct. When you think something is true, finding evidence that confirms our thinking means maybe we are right. Finding one piece of evidence that refutes our thinking, means we are wrong. This is how hypothesis works, when we find one thing that indicates we are incorrect, we are incorrect, evidence that proves we are correct, does not mean we are correct. The hypothesis is explored for veracity by finding information that either makes very specific predictions or refutes our thinking and the hypothesis (the hypothesis is falsifiable). For project management, product development, or business at large, when we take on great actions based upon things that confirm what we are thinking, we put our project and the company at risk.
This is especially valid for engineering and product development work, for example, software development. We should actively seek opportunities to prove what we believe is wrong, and if our thinking withstands these challenges, we might actually be correct in our thinking.
Anchoring bias impacts project management, aplenty. Have you ever had a discussion with your boss, perhaps they ask you how long will something take to accomplish, a portion of work or objective? Perhaps the project manager is asked for a quick estimate of how long and how much money a project will take in a brief exchange. This shoot from the hip can come back to haunt if this preliminary work actually translates into a project. Going through the business objectives and the project scope produces an estimate that has a higher level of diligence and maybe more in line with the actual effort. Upon presenting this possibly more accurate number, there is pushback and skepticism by the management, especially the person that made the impromptu query.
This reluctance to accept the new information is an example of anchoring bias. This is not just for estimates, but any first piece of information acquired will conflict with subsequent information, the former being perceived as more accurate. This does not apply to just the organization’s management, but the project managers as well. These early “facts,” provide the base, and there is a reluctance to substantially move away from this information.
Projects are directed at business objectives, providing the planning and synchronization of efforts, reduction of risk, and management of the money on behalf of the organization to achieve those objectives. The latter has a bias that can get in the way of effective fiscal operation of our project (and by extension the company). For example, we secure some money for our project, our estimates indicate we need $200,000, and we define objectives of the work must accomplish. We begin work. At the end of the $200,000 we have not accomplished the project objectives.
What do we do? Rather than revisit the business case, including the cost for what was just learned during this part of the work, we dismiss the past spending. That money is gone, we cannot get it back, it has been sunk into the project and therefore no longer exists. It is difficult to walk away from that loss, if we stop now, that money is lost with no gain besides the learning. We rationalize that money away as a sunk cost that expenditure does not count regarding the business case, so we are effectively starting from where we now find ourselves when it comes to the business case. The new estimates alone will provide the business case estimates and secured funding (for example another $300,000).
The business case revisited without considering this earlier expenditure(loss). This gives us a poor view of the true cost of the project and the work, and an understanding of the payback period and any other sort of financial metric that a project may be assessed. Is this project worth undertaking (there is a big difference between $200,000 and $500,000 payback)? Will there be a compelling business case (and by business case we are talking about Return On Investments - ROI or Internal Rate of Return - IRR)? Continuing on with this project when the business case is getting weak, may lead us to overlook another project that has a more probable benefit to the company, this represents an opportunity cost.
Specifically, the company has limited funds, talent, and resources, and choosing to do one thing, means there are some things we are not going to be able to do. Acting as if these sunk costs did not happen and evaluating the business case entirely on the new estimates for the accomplishment of the project objectives does not provide a true picture of the cost for the project, and therefore the benefit to the organization.
Survivor bias is when we concentrate on the survivors of situations and look to find the common element in that population. Do they have comparable processes? How are the organizations structured? Do they have comparable approaches to the work (outsourcing for example)? This common element must be the reason why each of these individuals survived (or what is their respective competitive advantage). The problem is, we have not looked at the failures (those that did not survive) or the failed projects. There is some probability that those failure events that we have not considered also may have those same elements – but we don’t see that (we did not specifically look) because they are not successful.
Excluding the organizations and projects that have failed provides only a small glimpse of the things that may have brought forth the success of those companies. It is possible those things we attribute to those organization’s success, may also happen at failing organizations, but we do not know, because we are not looking at the failures. There is much more that goes into the success of a project or business beyond these simple to see elements. It is not possible to see all the myriad of interactions, and innumerable stimuli and responses that result in the visible or able to determine the impact of these interactions on the outcome. Excluding projects or organizations that are deemed to have failed, tells only part of the story.
Because experts generally recognize just how much they don't know, they tend to underestimate their ability; or answer questions in a way that sounds reticent. There is recognition of dependencies, unknowns, or change of circumstances, and even subtle unknown emergent situations can radically change the results. On the other hand, people of a lower level of competency, often overestimate their competency, not having the same range of experiences from which to draw. It is easy to be over-confident when you are not aware of these factors that are often not readily observable or when insufficient experience precludes asking probing questions.
Thus, is the case of Dunning-Kruger. The more one knows and experiences, the more one knows there are things one does not know, and the rules may not be so hard and fast. Those of lower cognitive ability often overestimate their level of competence with the subject matter, and can outwardly appear to be quite confident and knowledgeable. In projects, we may make our plans based upon answers from the confident team members, that are not sufficiently competent, and find accepting the guidance from those that are reluctant to state with some surety difficult.
In our haste to move a project quickly, we take actions based upon things we think we know. Some of that will be based upon facts, and much more of that will be based upon perceptions that are influenced by these cognitive biases. Projects can be impacted by these biases in any of the project phases (for example, initiating, execution, and monitoring). The only way to avoid the negative impacts of these biases is to be aware of these potentialities and take appropriate actions to prevent them.
References
[1][1] Vinney, C. (n.d.). How Cognitive Biases Increase Efficiency (And Lead to Errors). Retrieved October 07, 2020, from https://www.thoughtco.com/cognitive-bias-definition-examples-4177684