90% aller IT-Projekte überschreiten Budget oder Zeitplan. Nicht wegen schlechter Entwickler oder mangelhafter Tools – sondern wegen systematischer Denkfehler, die in unser Gehirn eingebaut sind.
Diese Denkfehler heißen Cognitive Biases. Und sie sabotieren deine Projekte.
Was sind Cognitive Biases?
Definition
COGNITIVE BIAS:
Systematische Abweichung von rationalem Denken.
WICHTIG:
- Nicht Dummheit oder Unwissen
- Unbewusst und automatisch
- Evolutionär sinnvoll, in komplexen Situationen schädlich
- Betrifft JEDEN – auch dich
Warum sie existieren
EVOLUTIONÄRE PERSPEKTIVE:
Schnelle Entscheidungen waren überlebenswichtig.
STEINZEIT:
"Ist das ein Raubtier?" → Schnell reagieren = überleben
False Positive (Flucht ohne Grund) = wenig Kosten
False Negative (nicht fliehen) = Tod
HEUTE:
"Wie lange dauert das Projekt?" → Systematisch unterschätzen
Schnelle Schätzung fühlt sich richtig an
Konsequenz kommt verzögert
Die 10 gefährlichsten Biases für Projekte
1. Planungsfehlschluss (Planning Fallacy)
DEFINITION:
Systematische Unterschätzung von Zeit, Kosten und Risiken.
BEISPIEL:
Schätzung: "Das dauert 2 Wochen"
Realität: 6 Wochen
WARUM ES PASSIERT:
- Wir planen den Best Case
- Wir ignorieren vergangene Erfahrungen
- Wir unterschätzen Komplexität
STATISTIK:
- 90% der Projekte überschreiten die Schätzung
- Durchschnittliche Überschreitung: 27%
- Bei großen IT-Projekten: 45%
Gegenmaßnahme:
REFERENCE CLASS FORECASTING:
Statt: "Wie lange dauert DIESES Projekt?"
Frage: "Wie lange haben ÄHNLICHE Projekte gedauert?"
PROZESS:
1. Ähnliche vergangene Projekte identifizieren
2. Deren tatsächliche Dauer ermitteln
3. Durchschnitt als Basis nehmen
4. Anpassungen nur mit expliziter Begründung
2. Bestätigungsfehler (Confirmation Bias)
DEFINITION:
Wir suchen nach Informationen, die unsere Meinung bestätigen.
BEISPIEL:
Team-Lead glaubt: "React ist die beste Wahl"
→ Liest nur positive React-Artikel
→ Ignoriert Problemberichte
→ Framework-Entscheidung steht schon fest
WARUM ES PASSIERT:
- Widerspruch fühlt sich unangenehm an
- Bestätigung fühlt sich gut an
- Effiziente Informationsverarbeitung
Gegenmaßnahme:
DEVIL'S ADVOCATE:
Jemand im Team MUSS Gegenargumente bringen.
PREMORTEM:
"Stell dir vor, das Projekt ist gescheitert.
Warum ist es gescheitert?"
RED TEAM:
Separates Team versucht, den Plan zu widerlegen.
3. Sunk Cost Fallacy
DEFINITION:
Festhalten an Entscheidungen wegen bereits investierter Ressourcen.
BEISPIEL:
"Wir haben 6 Monate in diesen Ansatz investiert.
Wir können jetzt nicht aufhören."
→ Weitere 6 Monate verschwendet
WARUM ES PASSIERT:
- Verluste wiegen schwerer als Gewinne
- Aufgeben fühlt sich wie Scheitern an
- Versunkene Kosten fühlen sich "real" an
DIE WAHRHEIT:
Die 6 Monate sind weg – egal was du tust.
Nur die Zukunft zählt.
Gegenmaßnahme:
ZERO-BASED THINKING:
"Wenn wir heute neu anfangen würden –
würden wir diesen Ansatz wählen?"
Nein? → Abbrechen, auch wenn es weh tut.
KILL CRITERIA:
VOR Projektstart definieren:
"Bei welchen Signalen brechen wir ab?"
4. Optimismus Bias
DEFINITION:
Wir überschätzen positive und unterschätzen negative Ergebnisse.
BEISPIEL:
"Bei UNS wird das klappen"
(obwohl 70% ähnlicher Projekte scheitern)
WARUM ES PASSIERT:
- Selbstüberschätzung
- Kontrolillusion
- Motivationserhalt
Gegenmaßnahme:
BASE RATES NUTZEN:
"Wie oft funktioniert das bei ANDEREN?"
EXTERNE PERSPEKTIVE:
"Was würde ein Außenstehender sagen?"
PESSIMIST IM TEAM:
Jemand der systematisch Risiken aufzeigt.
5. Ankereffekt (Anchoring)
DEFINITION:
Erste Information beeinflusst alle weiteren Schätzungen.
BEISPIEL:
Manager: "Das sollte in 2 Wochen machbar sein, oder?"
Entwickler: "Ähm... ja, vielleicht 3 Wochen"
(Ohne Anker hätte er 6 Wochen geschätzt)
WARUM ES PASSIERT:
- Erste Zahl dient als Referenzpunkt
- Anpassung von diesem Punkt ist zu gering
- Gilt auch für völlig irrelevante Zahlen!
Gegenmaßnahme:
SCHÄTZUNGEN VOR BEEINFLUSSUNG:
Jeder schätzt ZUERST alleine, ohne Diskussion.
PLANNING POKER:
Alle zeigen gleichzeitig ihre Schätzung.
Verhindert Anker durch frühe Aussagen.
KEINE FÜHRENDEN FRAGEN:
Nicht: "Das dauert doch nicht lange, oder?"
Sondern: "Wie lange wird das dauern?"
6. Verfügbarkeitsheuristik (Availability Heuristic)
DEFINITION:
Was leicht erinnerbar ist, halten wir für wahrscheinlich.
BEISPIEL:
Kürzlich gab es einen Security Breach.
→ Security wird überprioritisiert
→ Andere Risiken werden vernachlässigt
WARUM ES PASSIERT:
- Lebhafte Erinnerungen dominieren
- Medienberichte verzerren Wahrnehmung
- Emotionale Events bleiben hängen
Gegenmaßnahme:
SYSTEMATISCHE RISIKOANALYSE:
Nicht: "Was fällt mir ein?"
Sondern: Checkliste aller Risikokategorien
DATEN STATT GEFÜHL:
"Wie oft ist das statistisch passiert?"
Nicht: "Ich erinnere mich an..."
7. Gruppendenken (Groupthink)
DEFINITION:
Gruppen treffen schlechtere Entscheidungen durch Konformitätsdruck.
SYMPTOME:
- Illusion der Einmütigkeit
- Selbstzensur von Bedenken
- Direkter Druck auf Andersdenkende
- Stereotypisierung von Außenstehenden
BEISPIEL:
Im Meeting: Stille bei "Hat jemand Bedenken?"
Später einzeln: "Ich fand das von Anfang an riskant"
Gegenmaßnahme:
PSYCHOLOGISCHE SICHERHEIT:
Bedenken müssen belohnt, nicht bestraft werden.
ANONYMES FEEDBACK:
Schriftlich vor der Diskussion
DEVIL'S ADVOCATE PFLICHT:
Rotierende Rolle, die widersprechen MUSS
LEADER SPRICHT ZULETZT:
Hierarchie beeinflusst Meinungen
8. Dunning-Kruger-Effekt
DEFINITION:
Inkompetenz führt zu Überschätzung der eigenen Fähigkeiten.
BEISPIEL:
Junior Dev: "Microservices? Klar, mach ich in 2 Wochen!"
Senior Dev: "Das ist komplex. Lass mich analysieren..."
WARUM ES PASSIERT:
- Um zu wissen, dass man etwas nicht kann,
muss man es teilweise können
- Anfänger sehen die Komplexität nicht
Gegenmaßnahme:
ERFAHRUNG EINBEZIEHEN:
Seniors schätzen, Juniors lernen
ZWEITMEINUNGEN:
Bei Unsicherheit externen Experten fragen
RETROSPEKTIVEN:
Schätzungen vs. Realität systematisch vergleichen
9. IKEA-Effekt
DEFINITION:
Wir überbewerten Dinge, die wir selbst erstellt haben.
BEISPIEL:
"Mein selbstgebautes Framework ist besser als React"
(Objektiv: Nein)
WARUM ES PASSIERT:
- Emotionale Bindung durch Aufwand
- Rechtfertigung der Investition
- Stolz auf eigene Arbeit
Gegenmaßnahme:
EXTERNE EVALUATION:
Jemand ohne Beteiligung bewertet
BUILD VS. BUY FRAMEWORK:
Objektive Kriterien VOR der Entwicklung
REGELMÄSSIGE REVIEWS:
"Würden wir das heute noch so bauen?"
10. Eskalierendes Commitment
DEFINITION:
Verstärkte Investition in eine scheiternde Vorgehensweise.
BEISPIEL:
Projekt läuft schlecht
→ "Wir brauchen nur mehr Ressourcen"
→ Mehr Leute werden hinzugefügt
→ Projekt läuft noch schlechter
→ "Wir brauchen NOCH mehr Ressourcen"
→ ...
WARUM ES PASSIERT:
- Sunk Cost Fallacy
- Gesichtsverlust vermeiden
- Hoffnung auf Turnaround
Gegenmaßnahme:
EXTERNE REVIEWS:
Unbeteiligte bewerten Projektgesundheit
KILL CRITERIA:
Vorab definierte Abbruchbedingungen
FRISCHES TEAM:
Neue Perspektive ohne emotionale Bindung
Biases in typischen Projektsituationen
Beim Schätzen
TYPISCHE BIASES:
- Planungsfehlschluss
- Ankereffekt
- Optimismus Bias
GEGENMASSNAHMEN:
1. Unabhängige Schätzungen (Planning Poker)
2. Reference Class Forecasting
3. Puffer einplanen (20-30%)
4. Schätzung von Seniors validieren
Bei Technologie-Entscheidungen
TYPISCHE BIASES:
- Confirmation Bias
- IKEA-Effekt
- Verfügbarkeitsheuristik
GEGENMASSNAHMEN:
1. Objektive Kriterien VOR Recherche
2. Devil's Advocate
3. Proof of Concept mit mehreren Optionen
4. Externe Expertise einholen
Bei Projektkorrekturen
TYPISCHE BIASES:
- Sunk Cost Fallacy
- Eskalierendes Commitment
- Gruppendenken
GEGENMASSNAHMEN:
1. Zero-Based Thinking
2. Externe Projektreviews
3. Kill Criteria
4. Blameless Culture
Team-Praktiken gegen Biases
1. Regelmäßige Retrospektiven
FORMAT:
- Was haben wir geschätzt vs. was war real?
- Welche Annahmen waren falsch?
- Welche Biases haben wir beobachtet?
WICHTIG:
- Blameless: Fehler sind menschlich
- Systematisch: Patterns erkennen
- Actionable: Konkrete Verbesserungen
2. Red Team Reviews
PROZESS:
1. Separates Team erhält Projektplan
2. Aufgabe: Den Plan angreifen
3. Schwachstellen identifizieren
4. Gegenmaßnahmen entwickeln
WANN:
- Vor großen Entscheidungen
- Bei kritischen Projekten
- Regelmäßig bei Langzeitprojekten
3. Anonyme Risiko-Sammlung
PROZESS:
1. Jeder schreibt Risiken auf (anonym)
2. Alle Risiken werden gesammelt
3. Gemeinsame Priorisierung
4. Maßnahmen definieren
WARUM ANONYM:
- Hierarchie wird neutralisiert
- Ehrlichkeit steigt
- Unpopuläre Meinungen werden gehört
Checkliste: Bias-Awareness im Projekt
VOR DEM PROJEKT:
□ Reference Class Forecasting durchgeführt?
□ Kill Criteria definiert?
□ Schätzungen unabhängig erhoben?
□ Puffer eingeplant?
WÄHREND DES PROJEKTS:
□ Devil's Advocate Rolle besetzt?
□ Regelmäßige externe Reviews?
□ Retrospektiven mit Bias-Fokus?
□ Anonyme Feedback-Kanäle?
BEI PROBLEMEN:
□ Zero-Based Thinking angewendet?
□ Sunk Costs ignoriert?
□ Externe Perspektive eingeholt?
□ Kill Criteria überprüft?
Fazit: Mit Biases leben lernen
Cognitive Biases verschwinden nicht durch Wissen. Sie sind Teil unseres Denkens. Aber wir können Systeme bauen, die sie ausgleichen:
Die wichtigsten Prinzipien:
- Awareness: Wissen, dass Biases existieren
- Strukturen: Prozesse, die Biases neutralisieren
- Diversität: Unterschiedliche Perspektiven einbeziehen
- Daten: Bauchgefühl durch Evidenz ersetzen
- Feedback: Systematisch aus Fehlern lernen
Die unbequeme Wahrheit:
Du bist nicht rational. Ich bin es nicht. Niemand ist es. Aber Teams mit guten Prozessen können bessere Entscheidungen treffen als jedes Individuum.
Du willst verstehen, wie du als Team bessere Entscheidungen triffst? Unser Guide zu Entscheidungen treffen zeigt Frameworks wie RAPID und Pre-Mortem für strukturierte Entscheidungsprozesse.
