Zwischen „die Entscheidung ist getroffen und dokumentiert“ und „die Entscheidung verändert die Arbeit“ liegt eine messbare Latenz. Die meisten Programme steuern das Dokumentieren — nicht die Latenz.
Executive Summary
  • Entscheidungen wirken nicht in dem Moment, in dem sie protokolliert werden, sondern erst, wenn sie in Plänen, Tools und Arbeitsweisen angekommen sind. Dazwischen vergehen in großen Programmen oft Wochen.
  • Diese Latenz entsteht in fünf Phasen: Erkennen des Entscheidungsbedarfs, Herstellen der Entscheidungsreife, Gremientermin, Kommunikation, Umsetzung im Tool oder Prozess. Jede Phase hat eigene Wartezeiten.
  • Wer die Latenz misst und pro Phase steuert — etwa über ein Decision Log mit Latenz-Feldern und Eskalationsstufen mit Zeitbudget — gewinnt Geschwindigkeit ohne zusätzliche Gremien.

Beobachtung

In Steering-Runden großer IT-Programme wiederholt sich ein Muster: Eine Entscheidung wird getroffen, sauber protokolliert, im Decision Log abgelegt — und drei Wochen später arbeiten zwei Workstreams weiterhin nach dem alten Stand. Nicht aus Widerstand, sondern weil die Entscheidung sie schlicht noch nicht erreicht hat: Der Releaseplan wurde nicht angepasst, das Jira-Board zeigt die alte Priorisierung, der Lieferant wartet auf die formale Beauftragung.

Auffällig ist, was in solchen Programmen gemessen wird: die Anzahl offener und geschlossener Entscheidungen. Was fast nie gemessen wird: die Zeit zwischen dem Moment, in dem ein Entscheidungsbedarf erkennbar war, und dem Moment, in dem die getroffene Entscheidung tatsächlich Arbeit verändert hat. Diese Beobachtung stammt aus eigener Projektpraxis in Programm- und PMO-Mandaten; sie ist keine Studienaussage.

Einordnung

Die Forschung zu Programm-Misserfolg stützt die Relevanz des Musters indirekt. In der BCG-Untersuchung von 2024 über 1.000 Unternehmen in 59 Ländern nennen rund 60 Prozent der Befragten das Fehlen eines aktiven PMO — eines, das Wertlieferung überwacht und entstehende Risiken identifiziert — als zentrale Ursache des Scheiterns großer Technologieprogramme.1 Ein PMO, das Entscheidungen nur dokumentiert, ist in diesem Sinn passiv: Es verwaltet den Beschlusszustand, nicht die Wirksamkeit. Die Verbindung zwischen diesem Befund und dem hier beschriebenen Latenz-Begriff ist eine eigene Interpretation, keine Aussage der Studie.

Auch die Governance-Forschung legt nahe, dass Steuerungswirkung primär über die Qualität und Geschwindigkeit von Entscheidungen entsteht. Turner (2020) kommt in der Analyse von sechs Fallstudien zu dem Schluss, dass Governance vor allem ein Umfeld schafft, in dem kompetente Personen wirksame Entscheidungen treffen können — der Zusammenhang zwischen Governance und Projektergebnis läuft also wesentlich über die Entscheidungsarchitektur.2 Sirisomboonsuk und Kollegen (2018) fanden auf Basis von 282 auswertbaren Antworten, dass sowohl IT- als auch Projekt-Governance positiv mit der Projektleistung zusammenhängen — und dass gerade ihre gegenseitige Abstimmung die Leistung stützt.3 Und die Meta-Analyse von Tubre und Collins (2000) zeigt, dass Rollenunklarheit negativ mit Leistung korreliert4 — besonders relevant für temporäre Programmstrukturen mit überlappenden Verantwortlichkeiten, in denen oft unklar bleibt, wer eine offene Frage überhaupt entscheiden darf.

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 hat. Sie zerfällt in fünf messbare Phasen:

  1. Erkennen: Ein Thema wird als entscheidungsbedürftig identifiziert und benannt — nicht nur als Risiko oder offener Punkt geführt.
  2. Entscheidungsreife: Optionen, Konsequenzen und Empfehlung liegen vor. Häufig die längste Phase, weil niemand explizit dafür verantwortlich ist.
  3. Gremientermin: Die Entscheidung wartet auf den nächsten Termin des zuständigen Gremiums — bei monatlichem Takt im Schnitt zwei Wochen Wartezeit, unabhängig von der Dringlichkeit.
  4. Kommunikation: Die Entscheidung erreicht alle, deren Arbeit sie verändert — einschließlich Lieferanten und angrenzender Workstreams.
  5. Umsetzung: Pläne, Boards, Backlogs, Verträge und Prozesse spiegeln den neuen Stand wider.

Der Punkt dieser Zerlegung: Die Gesamtlatenz ist steuerbar, sobald sichtbar wird, in welcher Phase Zeit verloren geht. Ein Programm mit schnellen Gremien, aber ohne Verantwortung für Entscheidungsreife hat ein anderes Problem als eines, das Beschlüsse fasst, aber nicht in die Tools bringt.

Vier Ursachen von Decision Latency

Die fünf Phasen zeigen, wann Zeit verloren geht. Ebenso wichtig ist, warum. In der Praxis lassen sich vier Ursachentypen unterscheiden — jeder verlangt eine andere Gegenmaßnahme:

  1. Informations-Latenz. Die Entscheidung kann nicht getroffen werden, weil Daten, Kosten, Risiken oder Auswirkungen fehlen. Abhilfe: Mindestanforderungen an Entscheidungsvorlagen, eine benannte Verantwortung für die Vorbereitung, Zugriff auf die führenden Quellsysteme.
  2. Autoritäts-Latenz. Es ist unklar, wer entscheiden darf. Abhilfe: ein Decision-Rights-Modell mit Schwellenwerten nach Budget, Scope, Risiko und Architekturwirkung sowie eindeutige Eskalationsstufen.
  3. Kapazitäts-Latenz. Die entscheidungsbefugte Rolle hat keine Zeit, oder das Gremium tagt zu selten. Abhilfe: asynchrone Freigaben, delegierte Entscheidungsrechte, außerordentliche Sitzungen für kritische Termine.
  4. Konflikt-Latenz. Die Entscheidung fällt nicht, weil Stakeholder unterschiedliche Ziele verfolgen. Abhilfe: den Zielkonflikt offenlegen, ein Entscheidungsprinzip definieren und Sponsor oder Business Owner anhand der priorisierten Projektziele entscheiden lassen.

Anwendung in Projekten

Drei Praktiken haben sich in der Projektarbeit bewährt:

  • Decision Log mit Latenz-Feldern. Das Entscheidungsregister erhält neben Titel, Owner und Status drei Datumsfelder: Bedarf erkannt, Entscheidung getroffen, Umsetzung bestätigt. Schon die einfache Auswertung dieser Felder zeigt, wo das Programm strukturell Zeit verliert.
  • Entscheidungsreife als Eingangskriterium. Ein Punkt kommt erst auf die Gremienagenda, wenn Optionen, Konsequenzen und Empfehlung vorliegen — und es gibt eine benannte Rolle, die diese Reife herstellt. Das verkürzt Phase 2 und verhindert Vertagungen.
  • Eskalationsstufen mit Zeitbudget. Jede Eskalationsstufe erhält ein explizites Zeitbudget (etwa: fünf Arbeitstage auf Workstream-Ebene, dann automatische Vorlage im Programmboard). Entscheidungen warten dadurch nicht mehr stillschweigend auf den nächsten regulären Termin.

Mögliche Kennzahlen

Sobald die Latenz erfasst wird, lässt sie sich wie eine Durchlaufzeit auswerten. Fünf Kennzahlen haben sich als aussagekräftig erwiesen:

  • Median Decision Latency — die mittlere Zeit zwischen Entscheidungsreife und Beschluss.
  • Critical Decision Latency — die Entscheidungsdauer für Themen mit hoher Termin-, Budget- oder Risikowirkung.
  • Decision Reopen Rate — der Anteil bereits getroffener Entscheidungen, die ohne neue Fakten wieder aufgemacht werden.
  • Decision Implementation Lag — die Zeit zwischen Beschluss und tatsächlicher Umsetzung.
  • Cost of Waiting — geschätzte Kosten aus blockierten Ressourcen, Parallelarbeit, Nacharbeit, verpassten Terminen und verlängerten Lieferanteneinsätzen.

Diese Kennzahlen sollen keine Entscheidungen künstlich beschleunigen — eine schnelle falsche Entscheidung bleibt falsch. Ihr Zweck ist, unnötige Wartezeit sichtbar zu machen.

Ein wirksames Decision Paper

Eine Entscheidungsvorlage sollte nicht primär den gesamten Hintergrund dokumentieren, sondern 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. Nicht-Entscheidung wird oft behandelt, als bliebe der Status quo einfach bestehen. Tatsächlich ist sie selbst eine Entscheidung — häufig eine für Verzögerung, höhere Kosten oder wachsende Risiken.

Grenzen

Decision Latency ist ein Praxisbegriff, kein empirisch validiertes Konstrukt; die Phaseneinteilung ist eine Arbeitshypothese aus Projekterfahrung. Nicht jede Entscheidung verträgt Beschleunigung — bei architektur- oder vertragskritischen Fragen ist eine längere Reifephase oft die richtige Investition. Und die Messung selbst erzeugt Aufwand: In kleinen Projekten mit kurzen Wegen lohnt ein instrumentiertes Decision Log selten. Der Ansatz zielt auf Programme, in denen Entscheidungen mehrere Gremien, Lieferanten und Systeme durchlaufen müssen.