Decision Latency: Warum dokumentierte Entscheidungen trotzdem zu spät wirksam werden.

Eine Entscheidung ist getroffen und dokumentiert. Bis sie die Arbeit tatsächlich verändert, vergeht jedoch messbare Zeit. Viele Programme steuern die Dokumentation der Entscheidung, aber nicht diese Zeitspanne.

Beobachtung

In Steering-Runden großer IT-Programme wiederholt sich ein Muster. Eine Entscheidung wird getroffen, sauber protokolliert und im Decision Log abgelegt. Drei Wochen später arbeiten zwei Workstreams trotzdem nach dem alten Stand. Das liegt selten an Widerstand. Die Entscheidung hat die Teams schlicht noch nicht erreicht. Der Releaseplan ist nicht angepasst, das Jira-Board zeigt die alte Priorisierung, und der Lieferant wartet noch auf die formale Beauftragung.

Gemessen wird in solchen Programmen meist die Zahl offener und geschlossener Entscheidungen. Kaum ein Programm misst dagegen, wie viel Zeit zwischen dem erkennbaren Entscheidungsbedarf und der tatsächlich veränderten Arbeit vergeht. Diese Beobachtung stammt aus eigener Praxis in Programm- und PMO-Mandaten. Erste Studien dazu beginnen im November 2026.

Einordnung

Die Forschung zum Scheitern großer Programme stützt die Relevanz dieses Musters indirekt. In der BCG-Untersuchung von 2024 mit rund 1.000 Unternehmen in 59 Ländern nennen rund 60 Prozent der Befragten das Fehlen eines aktiven PMO als zentrale Ursache für das Scheitern großer Technologieprogramme. Gemeint ist ein PMO, das die Wertlieferung überwacht und entstehende Risiken erkennt.

Ein PMO, das Entscheidungen nur dokumentiert, ist in diesem Sinn passiv. Es verwaltet, was beschlossen wurde, verfolgt aber nicht, ob der Beschluss wirkt. Die Verbindung zwischen dem BCG-Befund und dem Begriff der Decision Latency ist eine eigene Interpretation und keine Aussage der Studie.

Zwei Studien zur Projekt-Governance zeigen, dass Steuerung über Entscheidungen wirkt. Turner (2020) hat in sechs Fallstudien untersucht, wie Governance die Entscheidungen in Projekten beeinflusst. Er kommt zu dem Schluss, dass Governance vor allem einen Rahmen schaffen soll, in dem kompetente Personen gute Entscheidungen treffen können. Sirisomboonsuk und Kollegen (2018) haben 282 Antworten aus einer Befragung ausgewertet. Danach hängen sowohl IT-Governance als auch Projekt-Governance positiv mit der Projektleistung zusammen, und ihre Abstimmung aufeinander stützt die Leistung zusätzlich. Keine der beiden Studien misst, wie lange eine Entscheidung braucht, bis sie wirkt. Die Folgerung, dass auch diese Zeitspanne ein Hebel der Governance ist, ist eine eigene Ableitung.

Der Begriff: Decision Latency

Decision Latency bezeichnet die Zeitspanne zwischen dem Erkennen eines Entscheidungsbedarfs und dem Moment, in dem die getroffene Entscheidung die tatsächliche Arbeit verändert. Sie lässt sich in fünf messbare Phasen gliedern.

1. Erkennen: Ein Thema wird als entscheidungsbedürftig erkannt und benannt. Es wird also nicht nur als Risiko oder offener Punkt geführt.
2. Entscheidungsreife: Optionen, Konsequenzen und eine Empfehlung liegen vor. Diese Phase dauert oft am längsten, weil niemand ausdrücklich für sie verantwortlich ist.
3. Gremientermin: Die Entscheidung wartet auf die nächste Sitzung des zuständigen Gremiums. Tagt das Gremium monatlich, wartet ein Thema im Schnitt zwei Wochen, unabhängig davon, wie dringend es ist.
4. Kommunikation: Die Entscheidung erreicht alle, deren Arbeit sie betrifft, einschließlich der Lieferanten und angrenzender Workstreams.
5. Umsetzung: Pläne, Boards, Backlogs, Verträge und Prozesse bilden den neuen Stand ab.

Mit dieser Gliederung wird sichtbar, in welcher Phase Zeit verloren geht, und erst dann lässt sich die Gesamtdauer steuern. Ein Programm mit schnellen Gremien, in dem niemand für die Entscheidungsreife verantwortlich ist, hat ein anderes Problem als ein Programm, das zügig beschließt, die Beschlüsse aber nicht in die Tools überträgt.

Vier Ursachen von Decision Latency

Die fünf Phasen zeigen, wann Zeit verloren geht. Ebenso wichtig ist die Frage, warum das geschieht. In der Praxis lassen sich vier Ursachen unterscheiden, und jede verlangt eine eigene Gegenmaßnahme.

1. Informations-Latenz: Die Entscheidung kann nicht getroffen werden, weil Daten, Kosten, Risiken oder Auswirkungen fehlen. Abhilfe schaffen Mindestanforderungen an Entscheidungsvorlagen, eine benannte Verantwortung für die Vorbereitung und der Zugriff auf die führenden Quellsysteme.
2. Autoritäts-Latenz: Es ist unklar, wer entscheiden darf. Abhilfe schafft ein Modell der Entscheidungsrechte mit Schwellenwerten für Budget, Scope, Risiko und Architekturwirkung und mit eindeutigen Eskalationsstufen.
3. Kapazitäts-Latenz: Die entscheidungsbefugte Person hat keine Zeit, oder das Gremium tagt zu selten. Abhilfe schaffen asynchrone Freigaben, delegierte Entscheidungsrechte und außerordentliche Sitzungen vor kritischen Terminen.
4. Konflikt-Latenz: Die Entscheidung fällt nicht, weil die Beteiligten unterschiedliche Ziele verfolgen. Hier hilft es, den Zielkonflikt offenzulegen, ein Entscheidungsprinzip festzulegen und den Sponsor oder Business Owner auf Grundlage der priorisierten Projektziele entscheiden zu lassen.

Anwendung in Projekten

Die folgenden drei Praktiken stammen aus der Projektarbeit. Ihre Wirkung ist bisher nicht systematisch geprüft.

• Decision Log mit Latenz-Feldern: Das Entscheidungsregister erhält neben Titel, Owner und Status drei Datumsfelder. Sie halten fest, wann der Bedarf erkannt, wann entschieden und wann die Umsetzung bestätigt wurde. Schon eine einfache Auswertung dieser Felder zeigt, wo das Programm regelmäßig Zeit verliert.
• Entscheidungsreife als Eingangskriterium: Ein Thema kommt erst auf die Agenda des Gremiums, wenn Optionen, Konsequenzen und eine Empfehlung vorliegen. Eine benannte Rolle ist dafür verantwortlich, diese Reife herzustellen. Das verkürzt die zweite Phase und vermeidet Vertagungen.
• Eskalationsstufen mit Zeitbudget: Jede Eskalationsstufe erhält ein festes Zeitbudget, zum Beispiel fünf Arbeitstage auf Ebene des Workstreams. Danach wird das Thema automatisch dem Programmboard vorgelegt. So wartet keine Entscheidung stillschweigend auf den nächsten regulären Termin.

Mögliche Kennzahlen

Sobald die Latenz erfasst wird, lässt sie sich wie eine Durchlaufzeit auswerten. Dafür bieten sich fünf Kennzahlen an.

• Die Median Decision Latency ist die mittlere Zeit zwischen Entscheidungsreife und Beschluss.
• Die Critical Decision Latency ist die Entscheidungsdauer bei Themen mit großer Wirkung auf Termine, Budget oder Risiken.
• Die Decision Reopen Rate ist der Anteil bereits getroffener Entscheidungen, die ohne neue Fakten wieder geöffnet werden.
• Der Decision Implementation Lag ist die Zeit zwischen Beschluss und tatsächlicher Umsetzung.
• Cost of Waiting bezeichnet die geschätzten Kosten durch blockierte Ressourcen, Parallelarbeit, Nacharbeit, verpasste Termine und verlängerte Einsätze von Lieferanten.

Die Kennzahlen sollen Entscheidungen nicht künstlich beschleunigen, denn eine schnelle falsche Entscheidung bleibt falsch. Sie sollen unnötige Wartezeit sichtbar machen.

Ein wirksames Decision Paper

Eine Entscheidungsvorlage muss nicht den gesamten Hintergrund dokumentieren. Sie sollte sieben Fragen beantworten.

1. Was ist zu entscheiden?
2. Bis wann wird die Entscheidung gebraucht?
3. Welche realistischen Optionen gibt es?
4. Welche Auswirkung hat jede Option?
5. Was empfiehlt das verantwortliche Team?
6. Wer hält das Entscheidungsrecht?
7. Was passiert, wenn nicht entschieden wird?

Die letzte Frage ist besonders wichtig. Oft wird so getan, als bliebe ohne Entscheidung einfach der Status quo bestehen. Tatsächlich ist auch das Nichtentscheiden eine Entscheidung, häufig eine für Verzögerung, höhere Kosten oder wachsende Risiken.

Grenzen

Decision Latency ist ein Begriff aus der Praxis und kein empirisch validiertes Konstrukt. Die Einteilung in Phasen ist eine Arbeitshypothese aus Projekterfahrung. Nicht jede Entscheidung sollte beschleunigt werden. Bei Fragen, die Architektur oder Verträge betreffen, ist eine längere Vorbereitung oft gut investierte Zeit. Auch die Messung selbst verursacht Aufwand. In kleinen Projekten mit kurzen Wegen lohnt sich ein Decision Log mit Latenz-Feldern deshalb selten. Der Ansatz richtet sich an Programme, in denen Entscheidungen mehrere Gremien, Lieferanten und Systeme durchlaufen. Ab November 2026 wird das Modell in zwei Online-Experimenten und einer Umfrage geprüft.