Why even the most experienced experts fail in projects

We know them from training sessions and retrospectives—and yet they keep happening: cognitive biases. In IT projects, they influence planning and estimates, architectural decisions, requirements workshops, steering committees and daily stand-ups. Not because project teams are incompetent, but because humans simply aren't purely rational decision-making machines. This is especially dangerous in IT projects. We work with uncertainty, dependencies, technical risks, incomplete requirements, and high pressure to deliver. And that is exactly where cognitive biases thrive. My article shows you, how to critically question decisions, estimate efforts more realistically, and evaluate new insights objectively.

Confirmation Bias: When we only see what confirms our assumptions

The confirmation bias describes the tendency to select or interpret information in a way that confirms our existing beliefs. Anything that doesn't fit is overlooked, downplayed, or treated as an exception. This happens surprisingly often in IT projects. A product owner is convinced that users need a specific feature. Project managers believe that their schedules are realistic. After that, they primarily notice signals that support this view. Critical feedback is then seen as a disruption. A negative comment from a user interview is dismissed as an "isolated case". A stakeholder who mentions different priorities? "They just have different goals than the project."

Why is the confirmation bias dangerous?

The confirmation bias leads to projects being built on false assumptions. Requirements are not properly validated, risks remain invisible, and decisions seem well-founded even though the underlying information is biased. A particularly problematic aspect is that mistakes often only become visible late in the process. By then, a lot has already been invested, changes are expensive, and discussions become emotional—see the "Sunk Cost Fallacy."

How can you prevent this?

1. Actively force counter-hypotheses

First, it must be clear what is an explicit requirement and what is an implicit assumption behind a requirement. For every key assumption, you should ask:

"What would have to happen for us to consider our assumption incorrect?"

Examples:

• "How would we recognize that this feature is not important to customers at all?"
• "What technical signals would show that our architectural decision is unsustainable?"
• "What feedback would call our prioritization into question?"

These questions seem simple, but they shift the mindset. "We are looking for confirmation" becomes "We are testing a hypothesis". Instead of "we believe we are doing the right thing," we get closer to "we know we are doing the right thing."

2. Document assumptions visibly

Many assumptions remain unspoken (implicit). That is exactly what makes them dangerous. A simple assumption log is helpful here, turning assumptions from unspoken truths into testable items. Here is an example:

• Assumption: Users need an export function
• Impact if incorrect: High development effort with no benefit;
• How do we validate it?: User interviews, prototype testing
• By when?: Sprint 3
• Owner: Product Owner

3. Schedule reviews by outsiders

Those who are deeply involved in a solution and have invested a lot of time, often defend it unconsciously. That is why independent reviews by people who were not involved in the solution design are so valuable. Crucially, these reviews should not be seen as policing, but as protection against bias. Care must be taken to ensure that reviews are not delivered as destructive feedback, but provide constructive input for the project.

Planning Fallacy: When the plan only works if nothing goes wrong

The planning fallacy describes our tendency to underestimate effort, duration, and complexity. We plan as if everything will go perfectly: requirements are clear, interfaces work, stakeholders make quick decisions, and everyone is aligned. We plan the project we want, not the project we are likely to get.

Why is the planning fallacy so relevant in IT projects?

IT projects are full of uncertainty. Requirements change. Legacy systems behave differently than documented. Test data is missing. Security approvals and data privacy assessments take longer. As a result, we lose planned time. To compensate, for example, fewer tests are run or more technical debt is incurred. This reduces quality and leaves teams more stressed and dissatisfied. Usually, this ends in late and expensive corrections. The planning fallacy is therefore not just a planning problem. It quickly becomes a quality and trust issue. Yet experts are often expected to use their experience to accurately predict and assess these unknown factors.

How can you prevent this?

1. Plan using reference projects

Instead of asking, "How long do we think it will take?", teams should ask:

"How long did comparable tasks actually take in the past?"

This is known as the outside view. It forces us to look at the project from more than just an internal perspective. Using real data is especially helpful, such as lead times for similar features, the duration of past integrations, or the number of change requests from comparable projects. If a task has never taken less than 5 weeks in the last three projects, the plan for the new project should not schedule 2 weeks for it—even if everything seems much "clearer" beforehand this time.

2. Legitimize buffers instead of hiding them

Buffers are often frowned upon in projects. Yet they are a sign of professional planning. The key is to make them transparent and legitimize them. This makes the buffer understandable and negotiable.

Instead of "secretly adding some padding," you should communicate and justify the buffer openly: "We are planning a 15% risk buffer because we have external dependencies and unresolved boundary conditions."

3. Plan iteratively instead of creating false precision

The further a project is in the future, the more uncertain the plan. Nevertheless, detailed schedules are often created months in advance, suggesting a level of precision that simply does not exist.

A good plan is not a document created once and then defended. A good plan is a steering instrument. If a ship on its way from A to B spots an iceberg, it is better to navigate around it skillfully than to hope the hull is harder than the ice ahead of itis. Therefore, you should plan the near future in detail, the medium term roughly, and treat the distant future as a vision, updating it regularly based on new insights.

Sunk Cost Fallacy: When we keep going just because we have already invested so much

The Sunk Cost Cost Fallacy describes the tendency to stick with a decision because time, money, or energy has already been invested. Rationally speaking, past costs should play no role in future decisions. The only thing that matters is whether the next invested franc, day, or sprint is worth it. This is a very rational perspective, but unfortunately, we behave differently in projects. "We have already invested so much time, was it all for nothing?!" or "If we don't finish this, we'll look bad!." This is understandable, as no one likes to admit they made a wrong decision.

Why is the Sunk Cost Cost Fallacy particularly critical in IT projects?

IT projects quickly generate high upfront investments: concepts, architecture, code, interfaces, test cases, budget approvals. The more that has been invested, the harder it is to change course. As a result, teams continue to develop features that offer little to no benefit. Subprojects keep running even though they no longer support achieving the goals. The sunk costs just keep growing.

How can you prevent this?

1. Firmly schedule stop-or-go reviews

Instead of viewing cancellations as an exception or failure, they should be part of regular reviews. The following questions should be asked regularly, not just when the project is already in trouble:

• Is the original business case still valid?
• Have requirements or boundary conditions changed?
• Would we make the same decision again today?
• What future benefit justifies the continued effort, or is there a better alternative?

2. Define exit criteria in advance

Exit criteria are most effective when defined before emotions escalate. This way, a change of course is not perceived as a spontaneous panic reaction, but as a professionally prepared decision, making it easier to explain to management. For example, you could define in advance that if fewer than X% of pilot users use the feature, no further resources will be invested in it. Or, if the integration costs of the feature exceed the planned amount X, a new business case evaluation will be conducted.

3. Establish a culture of trust: Rethink instead of assigning blame

Many projects cling to wrong decisions for too long because a change of course is interpreted as personal failure. That is why we need a culture where new insights are not seen as a defeat. A good phrase for project teams is:

"A decision was understandable under the assumptions at the time. Now we have new information and are therefore making a new decision."

Successful projects plan for cognitive biases

Cognitive biases do not disappear just because we are aware of them. Even experienced project managers, architects, product owners, business analysts and test managers fall into these traps. Experience can even worsen the problem if it makes us overconfident.

Successful projects are therefore not only characterized by good methods and technical expertise.

They consciously create structures that help teams challenge assumptions, make risks visible, and adapt decisions when new insights emerge.

After all, successful IT projects do not happen because people think perfectly. They happen because teams know their imperfections—and cleverly build their way of working around them.

Which cognitive biases are holding you back from success? Let's take a look together! adesso combines technical and methodological expertise with pragmatism and conscious action—turning good decisions into sustainable project success. Get in touch with us!