Warum auch die erfahrensten Experten in Projekten scheitern

Wir kennen sie aus Trainings und Retrospektiven – und trotzdem passieren sie immer wieder: Denkfehler. In IT-Projekten beeinflussen sie Planung und Schätzungen, Architektur-entscheidungen, Anforderungsworkshops, Steering Committees und Daily Stand-ups. Nicht, weil Projektteams unfähig wären, sondern weil Menschen nun einmal keine rein rationalen Entscheidungsmaschinen sind. Gerade in IT-Projekten ist das gefährlich. Wir arbeiten mit Unsicherheit, Abhängigkeiten, technischen Risiken, unvollständigen Anforderungen und hohem Erwartungsdruck. Und genau dort fühlen sich Denkfehler besonders wohl. Mein Beitrag zeigt dir, wie du Entscheidungen kritisch hinterfragst, Aufwände realistischer einschätzt und neue Erkenntnisse neutral bewertest.

Confirmation Bias: Wenn wir nur noch sehen, was unsere Annahme bestätigt

Der Confirmation Bias beschreibt die Tendenz, Informationen so auszuwählen oder zu interpretieren, dass sie unsere bestehenden Überzeugungen bestätigen. Was nicht passt, wird übersehen, relativiert oder als Ausnahme behandelt. In IT-Projekten passiert das erstaunlich oft. Ein Product Owner ist überzeugt, dass Nutzer:innen eine bestimmte Funktion brauchen. Projektleiter glauben, dass ihre Terminpläne realistisch sind. Danach werden vor allem die Signale wahrgenommen, die diese Sicht stützen. Kritisches Feedback wirkt dann störend. Ein negativer Kommentar aus einem Nutzerinterview wird als «Einzelfall» bewertet. Ein Stakeholder, der andere Prioritäten nennt? „Der verfolgt einfach andere Ziele als das Projekt.“

Warum ist der Confirmation Bias gefährlich?

Der Confirmation Bias führt dazu, dass Projekte auf falschen Annahmen aufbauen. Anforderungen werden nicht sauber validiert, Risiken bleiben unsichtbar und Entscheidungen wirken fundiert, obwohl die Informationsbasis verzerrt ist. Besonders problematisch dabei ist, dass Fehler oft erst spät sichtbar werden. Dann ist bereits viel investiert, Anpassungen sind teuer und die Diskussion wird emotional, siehe «Sunk Cost Fallacy».

Was hilft dagegen?

1. Gegenhypothesen aktiv erzwingen

Zunächst muss klar sein, was eine explizite Anforderung ist und was eine implizite Annahme einer Anforderung ist. Zu jeder wichtigen Annahme sollte die Frage gestellt werden:

«Was müsste passieren, damit wir unsere Annahme als falsch betrachten?»

Beispiele:

• «Woran würden wir erkennen, dass diese Funktion für Kunden gar nicht wichtig ist?»
• «Welche technischen Signale würden zeigen, dass unsere Architekturentscheidung nicht trägt?»
• «Welche Rückmeldungen würden unsere Priorisierung infrage stellen?»

Diese Fragen wirken simpel, verändern aber die Denkhaltung. Aus «Wir suchen Bestätigung» wird «Wir testen eine Hypothese». Aus «wir glauben das richtige zu tun», kommen wir dem «wir wissen, dass wir das richtige tun» näher.

2. Annahmen sichtbar dokumentieren

Viele Annahmen bleiben unausgesprochen (implizit). Genau das macht sie gefährlich. Hilfreich ist ein einfaches Annahmen-Log, das die Annahmen von unausgesprochenen Wahrheiten zu prüfbaren Objekten macht. Hier ein Beispiel:

• Annahme: Nutzer benötigen eine Exportfunktion
• Auswirkung, falls falsch: Hoher Entwicklungsaufwand ohne Nutzen
• Wie validieren wir sie?: Nutzerinterviews, Prototypentest
• Bis wann?: Sprint 3
• Verantwortlich: Product Owner

3. Reviews durch Unbeteiligte einplanen

Wer tief in einer Lösung steckt und viel Zeit investiert hat, verteidigt sie oft unbewusst. Deshalb sind unabhängige Reviews von Personen, die nicht am Lösungsdesign beteiligt waren, so wertvoll. Wichtig ist dabei: Diese Reviews dürfen nicht als Kontrolle verstanden werden, sondern als Bias-Schutz. Dabei muss darauf geachtet werden, dass die Reviews nicht als destruktives Feedback erfolgen, sondern konstruktive Inputs für das Projekt liefern.

Planning Fallacy: Wenn der Plan nur funktioniert, solange nichts schief geht

Die Planning Fallacy beschreibt unsere Neigung, Aufwand, Dauer und Komplexität zu unterschätzen. Wir planen, als würde alles ideal laufen: Anforderungen sind klar, Schnittstellen funktionieren, Stakeholder entscheiden schnell und sind sich einig. Wir planen das Projekt, das wir gerne hätten — nicht das Projekt, das wahrscheinlich eintreten wird.

Warum ist die Planning Fallacy in IT-Projekten so relevant?

IT-Projekte bestehen aus Unsicherheit. Anforderungen verändern sich. Altsysteme verhalten sich anders als dokumentiert. Testdaten fehlen. Sicherheitsfreigaben und Datenschutzabklärungen dauern länger. Dabei geht uns geplante Zeit verloren. Um diese zu kompensieren, werden beispielsweise weniger Tests durchgeführt, oder mehr technische Schulden generiert. Dabei sinkt die Qualität und die Teams sind gestresster und unzufriedener. Meist endet dies in späten und teuren Korrekturen. Die Planning Fallacy ist deshalb nicht nur ein Planungsproblem. Sie wird schnell zu einem Qualitäts- und Vertrauensproblem. Dabei wird von Experten oft verlangt, dass sie aus ihrer Erfahrung heraus, diese unbekannten Faktoren korrekt vorhersehen und bewerten können.

Was hilft dagegen?

1. Mit Referenzprojekten planen

Statt zu fragen: «Wie lange glauben wir, dass es dauert?», sollten Teams die Frage stellen:

«Wie lange hat Vergleichbares in der Vergangenheit tatsächlich gedauert?»

Das ist die sogenannte Aussensicht. Sie zwingt uns, das Projekt nicht nur aus der Innensicht zu betrachten. Besonders hilfreich ist die Verwendung von echten Daten, zum Beispiel von den Durchlaufzeiten ähnlicher Features, der Dauer von vergangenen Integrationen oder der Anzahl Change Requests aus vergleichbaren Projekten. Wenn eine Arbeit in den letzten drei Projekten nie unter 5 Wochen gedauert hat, sollte der Plan des neuen Projekts für diese Arbeit nicht mit 2 Wochen geplant werden, auch wenn dieses Mal bereits vorab vieles „klarer“ scheint.

2. Puffer legitimieren, anstatt ihn zu verstecken

Puffer werden in Projekten oft ungern gesehen. Dabei sind sie ein Zeichen professioneller Planung. Entscheidend dabei ist, sie transparent zu machen und zu legitimieren. Dies macht den Puffer nachvollziehbar und verhandelbar.

Anstelle «Wir bauen heimlich etwas Luft ein», sollte man den Puffer offen kommunizieren und begründen: «Wir planen 15 % Risikopuffer, weil wir externe Abhängigkeiten und noch ungeklärte Randbedingungen haben.»

3. Iterativ planen statt Scheingenauigkeit erzeugen

Je weiter ein Projekt in der Zukunft liegt, desto unsicherer ist der Plan. Trotzdem werden oft detaillierte Terminpläne über Monate erstellt, die eine Genauigkeit suggerieren, die es gar nicht gibt.

Ein guter Plan ist kein Dokument, das einmal erstellt und dann verteidigt wird. Ein guter Plan ist ein Steuerungsinstrument. Wenn mit dem Schiff, auf dem Weg von A nach B, ein Eisberg erkannt wird, dann umschifft man diesen besser gekonnt, als darauf zu hoffen, dass der Rumpf härter als das Eis vor ihm ist. Deshalb sollte man die nahe Zukunft detailliert und die mittlere Zukunft grob planen, und die ferne Zukunft als Vision behandeln, und diese anhand neuer Erkenntnisse regelmässig aktualisieren.

Sunk Cost Fallacy: Wenn wir nur weitermachen, weil wir schon so viel investiert haben

Die Sunk Cost Fallacy beschreibt die Tendenz, an einer Entscheidung festzuhalten, weil bereits Zeit, Geld oder Energie investiert wurde. Rational betrachtet sollten vergangene Kosten für zukünftige Entscheidungen keine Rolle spielen. Entscheidend ist nur: Lohnt sich der nächste investierte Franken, Tag oder Sprint? Das ist eine sehr rationale Sichtweise, leider verhalten wir uns in Projekten anders. «Wir haben schon so viel Zeit investiert, war das jetzt alles umsonst?!», «Wenn wir das nicht zu Ende bringen, sehen wir schlecht aus!». Das ist verständlich, denn niemand gibt gerne zu, eine falsche Entscheidung getroffen zu haben.

Warum ist die Sunk Cost Fallacy in IT-Projekten besonders kritisch?

IT-Projekte erzeugen schnell hohe Vorleistungen: Konzepte, Architektur, Code, Schnittstellen, Testfälle, Budgetfreigaben. Je mehr investiert wurde, desto schwerer fällt ein Kurswechsel. So entwickeln Teams Features weiter, die kaum einen Nutzen bringen. Teilprojekte laufen weiter, obwohl sie die Zielerreichung nicht mehr unterstützen. Die bisher versenkten Kosten, werden immer grösser.

Was hilft dagegen?

1. Stop-or-Go-Reviews fest einplanen

Statt Abbrüche als Ausnahme oder Scheitern zu betrachten, sollten sie Teil regelmässiger Reviews sein. Dabei sollten folgende Fragen regelmässig gestellt werden, nicht erst, wenn das Projekt bereits in Schieflage ist:

• Gilt der ursprüngliche Business Case noch?
• Haben sich Anforderungen oder Rahmenbedingungen verändert?
• Würden wir heute wieder dieselbe Entscheidung treffen?
• Welcher zukünftige Nutzen rechtfertigt den weiteren Aufwand oder gibt es eine bessere Alternative?

2. Abbruchkriterien vorher definieren

Abbruchkriterien sind am wirksamsten, wenn sie vor der emotionalen Eskalation definiert werden. So wird ein Kurswechsel nicht als spontane Panikreaktion wahrgenommen, sondern als professionell vorbereitete Entscheidung, was sie gegenüber dem Management einfacher erklären lässt. Als Beispiel könnte man vorab definieren, dass wenn weniger als X % der Pilotnutzer die Funktion verwenden, keine weiteren Ressourcen darauf investiert werden. Oder, dass wenn die Integrationskosten des Features den geplanten Betrag X übersteigen, eine neue Business-Case-Bewertung erfolgt.

3. Eine Vertrauenskultur etablieren: Umdenken statt Schuld suchen

Viele Projekte halten zu lange an falschen Entscheidungen fest, weil ein Kurswechsel als persönliches Versagen interpretiert wird. Deshalb braucht es eine Kultur, in der neue Erkenntnisse nicht als Niederlage gelten. Ein guter Satz für Projektteams lautet:

«Eine Entscheidung war unter den damaligen Annahmen nachvollziehbar. Jetzt haben wir neue Informationen und entscheiden deshalb neu.»

Erfolgreiche Projekte planen Denkfehler ein

Denkfehler verschwinden nicht, nur weil wir sie kennen. Auch erfahrene Projektleiter:innen, Architekt:innen, Product Owner, Business Analyst:innen und Testmanager:innen tappen in diese Fallen. Erfahrung kann das Problem sogar verstärken, wenn sie uns zu sicher macht.

Erfolgreiche Projekte zeichnen sich deshalb nicht nur durch gute Methoden und fachliche Expertise aus.

Sie schaffen bewusst Strukturen, die Teams helfen, Annahmen zu hinterfragen, Risiken sichtbar zu machen und Entscheidungen bei neuen Erkenntnissen anzupassen.

Denn erfolgreiche IT-Projekte entstehen nicht dadurch, dass Menschen perfekt denken. Sie entstehen dadurch, dass Teams ihre Unvollkommenheit kennen – und ihre Arbeitsweise klug darum herum bauen.

Welche Denkfehler hindern dich an deinem Erfolg? Lass uns gemeinsam hinschauen! adesso verbindet fachliche und methodische Expertise mit Pragmatismus und bewusstem Handeln – damit aus guten Entscheidungen nachhaltige Projekterfolge werden. Sprich uns an!