“Im Spinnennetz gefangen (Opinion-Driven Decisions) vs. Kontrolle durch Struktur (OTSM)” 40–50 % des Entwicklungsaufwands entsteht durch vermeidbare Nacharbeit. Nicht durch technische Komplexität — durch fehlende Grundlagen. Eine empirische Bestandsaufnahme der wichtigsten Methoden: was belegt ist, was nur behauptet wird, und was wirklich funktioniert.
„Die Wahl einer Entwicklungsmethode hat eher mit dem Beitritt zu einer Sekte zu tun als mit einer technischen Entscheidung."
— Capers Jones, Namcook Analytics, 2015
Das gilt nicht nur für Software. Es gilt für FMEA, Agile, CMMI, Lean, OKR, PRINCE2 und Design Thinking gleichermaßen. Jede Methode hat ihre Gemeinde. Jede Gemeinde hat ihre Zeremonien. Die Ergebnisse? Bestenfalls mittelmäßig — wenn überhaupt messbar.
40–50 % des Gesamtaufwands eines Entwicklungsprojekts entstehen durch vermeidbare Nacharbeit. Nicht durch technische Schwierigkeit. Durch Nacharbeit. Die Ursachen sind seit Jahrzehnten dokumentiert und unwidersprochen:
Mangelhafte Entwicklungsprozesse
Fehlende Systemarchitektur
Ignoriertes Risikomanagement
Das Gleiche gilt für Organisation: 40–50 % weniger Aufwand sind erreichbar — wenn man die Grundlagen korrekt anwendet.
| Dimension | Bewertung |
|---|---|
| Nutzen laut Industrie | Fehler vor Auftreten erkennen, Risiken quantifizieren |
| Nutzen empirisch belegt | ✅ JA — in Luft-/Raumfahrt und Medizintechnik klar nachgewiesen (NASA, FAA, FDA) |
| Einführungskosten | 5.000–30.000 € |
| Betriebsaufwand | 5–15 % Entwicklungsaufwand |
| Realer ROI | ✅ Hoch — aber nur wenn Funktionen korrekt modelliert und Maßnahmen rückgekoppelt |
| Warum es scheitert | Excel-FMEA für den Audit. RPZ als Absolutwert. Keine Verbindung zum Design. |
| Kosten des Scheiterns | Boeing 737 MAX: ~20 Mrd. USD. Ursache: Prozesskonformität ohne Systemverständnis. |---
| Dimension | Bewertung |
|---|---|
| Nutzen laut Industrie | Zielausrichtung, Transparenz, Fokus |
| Nutzen empirisch belegt | ❌ NEIN — Google verwendete OKR und war erfolgreich. Kein Kausalnachweis. |
| Einführungskosten | 10.000–50.000 € |
| Realer ROI | ⚠️ Führt häufig zu kurzfristiger Metrik-Optimierung auf Kosten von Systemqualität. |---
Nach Abzug aller opinion-driven Methoden bleiben drei nachgewiesene Grundprinzipien:
1. RTFM — Read the Actual Requirements Wer die Realität nicht liest, entscheidet auf Basis von Meinung.
2. Echtes Requirements Engineering — Zweck vor Lösung Wer nicht weiß was gebraucht wird, kann es nicht liefern.
3. Einnahmen > Ausgaben — immer, ohne Ausnahme Das ist keine Wirtschaftstheorie. Das ist Physik.
Alle anderen Methoden sind Implementierungen dieser drei Prinzipien unter spezifischen Rahmenbedingungen. Wenn die Rahmenbedingungen sich ändern, müssen die Implementierungen sich ändern. Die Prinzipien nicht.
