Wer beim Auto einmal nachrechnet, merkt schnell: Ab etwa 100 km/h bringt höhre Geschwindigkeit kaum noch Zeitgewinn – aber er kostet. In Projekten macht man denselben Fehler in die andere Richtung. Man tritt aufs Gas, obwohl der Wagen längst am Limit ist, und nennt es Zeitdruck.
Die Grafik stammt von Oliver Hummel (Aufwandsschätzungen in der Software- und Systementwicklung) und zeigt etwas, das jeder schon gehört hat, der einmal “das muss aber bis Freitag fertig sein” gesagt bekam: Solange der gewünschte Zeitplan bei mindestens 75 % des realistisch geschätzten liegt, bleibt der Mehraufwand überschaubar. Fällt er darunter, kippt die Kurve – der Aufwand steigt auf das 1,4-Fache und mehr. Hummel nennt diesen Bereich die Todeszone: Mehr Druck erzeugt dort keine höhere Geschwindigkeit, nur höhere Kosten.
Das ist dieselbe Physik wie beim Auto. Der Unterschied: Beim Auto sieht man den Mehrverbrauch sofort am Tacho. Beim Projekt sieht man die Rechnung erst Monate später – in Nacharbeit, Eskalationen und Nachverhandlungen mit dem Kunden.
Die zwei Bremsen, die in keiner Kostenstelle stehen#
Die Todeszone ist die falsche Art zu beschleunigen: mehr Druck auf denselben Prozess. Es gibt aber einen Weg, ein Projekt schneller zu machen, ohne dafür zu bezahlen – wenn man vorher zwei Bremsen löst, die in den meisten Unternehmen niemand als Bremsen führt:
Bremse 1 – Tool-Synchronisation. Jede manuelle Übertragung von Daten zwischen zwei Systemen kostet mehr als die reine Arbeitszeit. Nach einer eigenen Modellrechnung (Annahmen offen; Basis: 5 Tools, 10 Sync-Verbindungen, 20 Mitarbeitende, 100 €/h) kostet die Stunde, in der jemand Daten von einem Tool in ein anderes trägt, 147,75 € statt 100 € – Kontextwechsel, Nacharbeit aus Drift und die Rückstellung für den Tag, an dem der Fehler beim Kunden auffällt, kommen oben drauf.
Bremse 2 – Datenkonsistenz. Was manuell übertragen wird, weicht irgendwann ab. In derselben Modellrechnung arbeiten rechnerisch 4,89 von 20 Vollzeitstellen faktisch nur gegen die eigene Tool-Landschaft – niemand hat das je beschlossen, es ist über Jahre gewachsen, ein Tool nach dem anderen.Ändern, “Wir haben uns dran gewöhnt.” oder “wir haben den Marktführer unter den Tools”, oder so.
Beide Zahlen sind Modellrechnungen mit offen liegenden Annahmen, keine Studie. Aber die Mechanik dahinter ist bei jedem Kunden dieselbe: Wer ein und denselben Fakt in drei Systemen pflegt, hat drei Chancen, dass er dreimal etwas anderes sagt.
Warum das keine Ingenieursarbeit ist#
Im Kern gibt es in der Entwicklung nur zwei echte Aufgaben: Datenpunkte schaffen – das ist Wissen – und Datenpunkte bewerten. Beides passiert am selben Objekt. Wer stattdessen eine Stunde damit verbringt, eine bereits vorhandene Zahl von Tool A nach Tool B zu übertragen, schafft kein neues Wissen und bewertet nichts. Er verschiebt nur Reibung von einem System ins nächste. - Das ist auch ein klassisches Thema mit den Präsentationen fürs Management - veraltet bevor gespeichert.
Genau hier setzen viele Lösungen an, ohne die Bremse zu lösen: KI-gestützte Synchronisations-Tools machen die Übertragung schneller und automatischer. Das senkt die 147,75 € pro Stunde, beseitigt aber nicht die Ursache – es bleiben zwei Systeme, zwei Wahrheiten, die künstlich synchron gehalten werden müssen, nur jetzt von einer Maschine statt einem Menschen. Die Drift verschwindet dadurch nicht, sie wird nur seltener sichtbar.
Der andere Weg ist, die Synchronisation überflüssig zu machen, statt sie zu beschleunigen: ein Datenmodell, in dem Anforderung, Merkmal, Test und Fehler auf demselben Objekt liegen, mit genau einem Eigentümer je Feld. Das ist die Architektur-Entscheidung hinter otsm.work – kein weiteres Werkzeug zwischen den Werkzeugen, sondern der Ort, an dem es nichts mehr zu synchronisieren gibt.
Rechnen Sie nach, bevor Sie entscheiden#
Wenn die Ursache stimmt – Tool-Fragmentierung erzwingt manuelle Übertragung, manuelle Übertragung erzeugt Drift –, dann beseitigt eine Konsolidierung auf ein gemeinsames Datenmodell beide Bremsen gleichzeitig. Messbar an den Sync-Stunden pro Monat und der Zahl der Drift-Vorfälle, die aktuell niemand zählt, und prüfbar: Läuft die Zahl innerhalb eines Quartals nach der ersten migrierten Arbeitsfolge erkennbar zurück?
Wer das für die eigene Organisation verantwortet – meist die Entwicklungs- oder Qualitätsleitung –, kann an einem Nachmittag grob abschätzen, wie groß der Hebel ist: alle manuellen Datenübertragungen aufschreiben, Quelle, Ziel, Stunden pro Woche, was im Fehlerfall passiert. Multiplizieren.
Wer das nicht tut, zahlt weiter die 147,75 € pro Sync-Stunde und die 4,89 von 20 Stellen, die dafür nie beschlossen wurden – und tritt dabei aufs Gas, in der Hoffnung, das mache das Projekt schneller.