Warum gute Planung nicht im Projektplan beginnt

Unsicherheit ist kein Planungsfehler

Wie belastbar ist ein Datum, wenn seine Voraussetzungen offen sind?

Ein konkreter Termin vermittelt zunächst Verbindlichkeit. Seine Aussagekraft hängt jedoch davon ab, welche Voraussetzungen erfüllt sein müssen, damit die geplante Dauer überhaupt realistisch ist.

In einem Transition-Szenario wurde das für mich besonders anschaulich. Für den Wissenstransfer und die anschließende Übernahme von Aufgaben war ein vergleichsweise kurzer Zeitraum vorgesehen. Diese Planung war ausdrücklich an mehrere Voraussetzungen geknüpft. Eine davon: Die benötigte Dokumentation musste zum Beginn der Transition verfügbar, vollständig und auf einem aktuellen Stand sein.

Der zeitliche Rahmen galt also nur unter bestimmten Bedingungen. Ob diese später tatsächlich erfüllt waren, ist für die Beobachtung gar nicht entscheidend. Relevant ist hier: Hinter dem konkreten Termin standen Voraussetzungen, deren eigener Status betrachtet werden musste.

Im Terminplan selbst sind solche Voraussetzungen jedoch oft weit weniger sichtbar als das Datum, das auf ihnen beruht. Ein Meilenstein lässt sich eindeutig eintragen. Ob alle Bedingungen erfüllt sind, unter denen er erreichbar ist, erschließt sich daraus noch nicht.

Hier entsteht ein Unterschied, der in Projektplänen leicht verloren geht:

Ein Datum kann präzise sein, ohne belastbar zu sein.

Seine Belastbarkeit hängt davon ab, ob diese Voraussetzungen tatsächlich tragen.

Warum nicht alles im Plan gleich sicher sein sollte

Nicht jede Aussage in einem Projekt besitzt zum selben Zeitpunkt die gleiche Belastbarkeit. Bei manchen Ergebnissen sind Umfang, Voraussetzungen und Abhängigkeiten so weit geklärt, dass eine verbindliche Zusage sinnvoll ist. Bei anderen fehlen dafür noch Informationen oder es bestehen Risiken, deren Auswirkungen sich noch nicht zuverlässig abschätzen lassen.

Ein Beispiel für dieses Prinzip findet sich im PI Planning des Scaled Agile Framework (SAFe). Dort wird zwischen committed und uncommitted objectives unterschieden. Die einen werden verbindlich zugesagt. Bei den anderen bleibt sichtbar, dass ihre Erreichbarkeit noch von offenen Faktoren abhängt. (Scaled Agile Framework: „PI Objectives“; SAFe.)

Interessant ist weniger die konkrete Methode als das dahinterliegende Prinzip: Ein Plan muss nicht so tun, als hätten alle seine Bestandteile denselben Grad an Sicherheit.

Unsicherheit kann so Teil der Aussage eines Plans sein, statt erst außerhalb des Plans erklärt werden zu müssen.

Was ein belastbarer Plan nicht verstecken darf

Wenn Termine von Voraussetzungen abhängen und nicht alle Bestandteile eines Projekts denselben Grad an Verbindlichkeit besitzen, sollte ein Plan genau diese Unterschiede erkennen lassen.

Gute Planung versucht nicht, Unsicherheit aus dem Projektplan zu verstecken. Sie macht sichtbar, wo sie noch vorhanden ist.

Ein belastbarer Plan muss nicht überall dieselbe Sicherheit ausstrahlen. Er sollte auch erkennen lassen, welche Aussagen bereits tragfähig sind – und welche noch von Annahmen, Voraussetzungen oder Entwicklungen abhängen.

Was passiert, wenn Änderungen plötzlich billig werden?

Mit KI-Agenten kommt eine weitere Frage hinzu: Was verändert sich an dieser Logik, wenn sich Entwürfe und Umsetzungsschritte wesentlich schneller erzeugen, prüfen und wieder verwerfen lassen?

Wie viel müssen wir dann überhaupt noch im Voraus festlegen?