Protecting Your Projects from Cognitive Bias

In 2017, the Behavioral Insights Team (BIT) from the UK was contracted to investigate the project management of London’s transport authority, and how time and costs could be better estimated and managed.⁵

The BIT’s in-depth analysis of London’s transport authority found that project management teams suffered from four cognitive biases that are exacerbated in group settings. Two of particular interest are:

1. The planning fallacy
2. Groupthink

This is interesting because conventional knowledge suggests that the benefit of teamwork is greater creativity, and hence more alternative ideas.

This case highlights the finite power of the brain even when many minds are brought together. (Note: Collective work is not always ineffective.)⁶ Humans rely on heuristics (mental shortcuts) to overcome our finite resources and these shortcuts often result in cognitive biases.⁷

For those managing projects both big and small, understanding how decision making is influenced by these mental shortcuts provides a better understanding of what can go wrong when estimating the timeline, budget, and success of a potential project.

In the example above about the BER airport disaster, we can see (in hindsight and as external viewers) that public works project managers seem to be unreasonably optimistic.

The planning fallacy describes this exact phenomenon, whereby people tend to underestimate the resources required for a project.⁸

Daniel Kahneman described in his 2012 book Thinking, Fast and Slow how this bias introduces unrealistic forecasts hinging on best-case scenarios.

Why does this happen?

It’s a matter of perspective-taking. When planning a new project, there is a strong tendency to take an “inside” perspective to our abilities: to focus on what makes up a project (internally) rather than looking at the external factors that will influence the delivery of the project tasks.^8,9

People rarely take into account their own past experiences with similar tasks, instead focusing on the future expected outcomes…[they] anchor future outcomes on plans and available scenarios of success, rather than past results, which leads to overly optimistic predictions.

This, more often than not, leads to a failure to consider and identify the “unknown unknowns.”¹⁰

Taking an outside view is recommended to keep the planning fallacy in check. This involves referencing similar past projects to form a baseline for completion times and budget. A word of caution here: This may seem obvious, but as research finds, people often ignore this information entirely when planning.

It is therefore recommended to try and collect “well-designed feedback,” as the BIT puts it.¹¹ This can be as simple as ensuring that failures are openly discussed and dissected, frequently. 

Agile implementation: The Agile Manifesto lists twelve principles. One of these is, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”¹²

Feedback is therefore an integral aspect of an agile team. Regular standup meetings happen weekly or more frequently and allow teammates to share progress, and to follow up on potential roadblocks.¹³

In the same light, “retrospectives” are bigger review sessions, like a built-in “breather” for the team.

Data collection is another way to avoid committing the planning fallacy. By keeping score on past performance, costs, and timing, better estimates for future projects can be gleaned. Keeping score doesn’t just consciously inform a team of their realistic performance. The way feedback is provided can also also activate unconscious biases in a positive way: The Behavioral Economics Team of Australia found that providing feedback to doctors on how they compared to other doctors on the rate of antibiotics they prescribed led to a 12.3% reduction in overall prescriptions.¹⁴

Agile implementation: Data collection is a built-in feature of agile management tools like Jira and Asana. Both allow a team to track the rate of task/issue completion in one sprint or week, depending on the format of your project.

The BIT report mentioned above recommends something called a “pre-mortem” developed by the researcher Gary Klein. The concept is very similar to the retrospective, but a pre-mortem is held at the onset of project planning.

A pre-mortem involves bringing all stakeholders together in a workshop to imagine that the project has failed. Stakeholders are asked to consider and ideate reasons why the project has failed. Afterwards the different stories are shared and used to help inform others about the problems they may not have independently considered (thereby considering the “outside factors”).

Pre-mortems are so effective that they “can improve a person’s ability to correctly identify reasons for future outcomes by 30 percent.”¹⁵ This also can help overcome groupthink, which we will cover next.

Agile implementation: During the planning phase of a sprint or project, a pre-mortem exercise (sometimes called a “futurespective”) can be easily integrated as a formalized moment for the team to pause and reflect.

The BIT also quoted more recent research into something called the segmentation effect as justification for setting aside time at the onset of a project to think about the individual tasks involved. Research from Forsyth and Burt found that when people were asked to estimate the time needed to complete a large task, the time they allocated to the large tasks was less than the summed total of what they allocated to their component parts.¹⁶

Agile implementation: Itemizing actions and tasks is a key aspect of the agile method. The planning phase of an agile team can take many forms, but usually the team members will all sit together, and estimate and vote on the size of component tasks. This makes it easier for the project manager to plan because then they have time and effort estimates from those who are actually doing the work, as well as data from historical task completion rates.

A peculiar outcome of group work is how a team’s output can be less than the sum of its parts. Group dynamics and the influence of a few can disable the normal process of discussion, questioning, and finally agreement in a way where conformity towards one view prevails instead of a full appraisal of all options.

What ends up happening is that groups cover common knowledge: Members discuss what they all know instead of questioning what people do not know.

A group is especially vulnerable to groupthink when its members are similar in background, when the group is insulated from outside opinions, and when there are no clear rules for decision making

As we have learned, taking an outside view is harder than it seems. Therefore, an easy way to do this is not to do it at all.

Instead, assign someone in the team to roleplay as the devil’s advocate.¹⁸

The devil’s advocate strategy was recommended by the BIT for London’s transportation group to integrate into early team discussions and planning sessions. How it works: One person in the project team (or someone from outside the organization) role-plays a competitor, trying to find faults with the planning and to challenge any decisions.

The practice is backed by research: People do not underestimate others’ time to complete a task. Rather, they only overestimate their own abilities.⁹

Agile implementation: If you work with company-wide dashboards, many teams can observe different boards. By integrating project completion into a dashboard, this invites fresh eyes and constructive feedback. However a devil’s advocate is not standard practice. To add it, simply assign someone during sprint planning who is in charge of finding flaws in plans, and questions the escalation of commitment.

Another way to prevent groupthink is through minor changes to the way a group discusses ideas.

Irving Janis, the formative researcher on groupthink, recommended that leaders speak last. Even flat hierarchies can display problems of following the leader.

Agile implementation: One of the twelve agile principles is to take a hands-off approach to management: “Give them [team members] the environment and support they need, and trust them to get the job done.”

The problem with groupthink starts with the team. Therefore one way to overcome this is to bypass the team altogether, or at least in the beginning.

The BIT recommends asking team members to consider the task or project before the first meeting, in a maneuver called “pre-commitment.” Here people consider the issues and potential solutions on their own before they can be influenced by the group.

In the same line, after the initial planning meeting is held, offer a second chance: at a subsequent planning session, begin the session by allowing all team members to voice any reservations that they may have developed over the period from discussion to the second meeting.

Agile implementation: In terms of groupthink, the agile method encourages frequent team collaboration, thereby making it susceptible to the biases of group dynamics. However, when planning tasks, agile encourages individual brainstorming before ideas are shared in the group: The Jira backlog function acts as a low-commitment store for ideas that can be finalized later (like a built-in second chance feature). Furthermore, because issues are not automatically assigned to employees, it gives the chance for each member to individually consider the best way to achieve it on their own time.

Berlin’s BER airport finally opened for passengers on November 1st, 2020, nine years after originally planned. Delays in project planning seem to be a common occurrence, but the scale of the BER airport debacle is remains remarkable (the first days of operations were still met with complications like a leaky roof).¹⁹ 

The good news is that if you are planning to go agile (or already are), you are likely already taking advantage of years of behavioral science research. That’s because the agile method is (indirectly) backed by peer-reviewed findings from the study of cognitive processes. By following the recommendations of agile, you can help to protect your team’s projects from bias.

Strategies to avoid the planning fallacy and groupthink:

1. Well-designed feedback: Meet with the team often and deliberate together. Share the good and bad of a project’s tasks and progress. Write it down and review it at the onset of future projects. Hold retrospectives at the end of the project.

2. Keep score: Integrate data-based tracking of task completion rates to use for future project planning.

3. Pre- and post-mortems: At the project onset ask the team to imagine themselves in the future and act as if the project has failed. Ideate on how and why this happened. At the project wrap up, review what actually happened and what was and was not expected. Keep note and use for future planning. 

4. Break down project to-dos into tasks that take between 30 minutes and 3 days: Extra effort and time spent planning how project sub-tasks can be broken down into itemized issues that take more than 30 min to complete, but no longer than 3 days, helps better estimate time required. Ask those working on the tasks to chip in on the estimation.

5. Assign a devil’s advocate: Offset groupthink by asking someone to play the contrarian during project planning meetings. 

6. Be mindful of group dynamics: Make a habit of leaders speaking last and hand over story estimation to the team.

7. Pre-commit but offer a second chance: Before the details of the “how” and “when” are decided, allow team members to consider the project on their own time. Then, allow for open discussion in a group. It’s even better if ideation can be done anonymously. In the same line, after the initial meeting, provide a follow-up where people can voice second guesses.