Was-wäre-wenn-Szenarioanalyse

Ziel

Die Was-wäre-wenn-Szenarioanalyse, in der Projektmanagementliteratur what-if scenario analysis genannt, wendet eine benannte Bedingung auf den Terminplan an und berechnet diesen anschliessend neu, um ihre Wirkung auf die Projektziele zu messen. Die Frage ist immer dieselbe: Was geschieht, wenn Szenario X eintritt? Ein Szenario ist eine beschreibbare Bedingung: eine verspätete Lieferung einer Hauptkomponente, eine verlängerte Projektierungsdauer, ein Streik oder eine Änderung im Bewilligungsverfahren.

Sie stützt zwei Entscheide. Der erste ist die Bemessung der Terminreserve, des zeitlichen Polsters, das die Projektleitung für Unvorhergesehenes zurückbehält: Die Analyse ersetzt einen pauschalen Prozentsatz durch eine Anzahl Wochen, die an benannte Bedingungen gebunden ist. Der zweite ist der Massnahmenplan je Szenario, eine im Voraus beschlossene Handlung. Das Ergebnis der Analyse ist ein Register der durchgespielten Szenarien, das für jedes die Änderung am Netzplan, die verfügbare Pufferzeit, den neu berechneten Endtermin und den getroffenen Entscheid festhält.

Der PMBOK Guide ordnet sie den Werkzeugen der Datenanalyse bei der Erstellung des Terminplans (§2.3.2.2) und bei dessen Steuerung (§2.3.2.3) zu. Sie kommt somit zu zwei Zeitpunkten zum Einsatz: vor der Verpflichtung, um zu beurteilen, ob der zugesagte Termin unter ungünstigeren Bedingungen als denen des Plans standhält; während der Ausführung, um Aufholoptionen zu vergleichen.

Einsatz

Wann einsetzen

• Benannte externe Bedrohung: beziffern, was eine verzögerte Bewilligung, ein Streik oder der Ausfall eines Einzellieferanten mit dem Endtermin macht, ausgehend von den bereits bewerteten Zeilen des Risikoregisters.
• Zu verteidigende Terminreserve: dem Steuerungsausschuss eine aus dem Netzplan hergeleitete Anzahl Wochen vorlegen statt einer ausgehandelten Pauschale.
• Vorgegebener Endtermin: die eingegangene Verpflichtung unter verschlechterten Bedingungen prüfen, bevor sie gegengezeichnet wird.
• Abweichung während der Ausführung: die Aufholoptionen am Netzplan vergleichen, bevor eine davon eingeleitet wird.

Wann nicht einsetzen

• Kein Netzplan vorhanden: Ein Balkendiagramm ohne Abhängigkeiten berechnet nichts neu; der Netzplan muss zuerst aufgebaut werden.
• Frage nach der Rangfolge zwischen Variablen: Welche am stärksten auf das Ergebnis wirkt, beantwortet die Sensitivitätsanalyse.
• Wahrscheinlichkeit, den verlangten Termin zu halten: Ein Szenario liefert einen Fall, die Monte-Carlo-Simulation liefert eine Verteilung von Endterminen.

Beschreibung

Das Szenario benennen

Ein Szenario wird in Worten geschrieben, bevor es zu einer Zahl wird. Es benennt einen Auslöser, eine Reichweite und eine Dauer: "Während der öffentlichen Auflage wird eine Einsprache eingereicht und die Rechtskraft der Baubewilligung verschiebt sich um acht Wochen", "Das Werk des Liftherstellers steht zwei Wochen still und die Lieferung verschiebt sich um drei Wochen". So formuliert, lässt es sich eindeutig in eine Änderung des Modells übersetzen. Vage formuliert, "der Lieferant ist im Verzug", lässt es sich nicht übersetzen.

Die Szenarien stammen aus dem Risikoregister, aus bekannten externen Bedrohungen vergleichbarer Projekte, aus vertraglichen Randbedingungen und aus dem regulatorischen Rahmen. In der Praxis behält man bei einem mittelgrossen Projekt drei bis sechs Szenarien, ausgewählt nach ihrer Plausibilität und dem Ausmass dessen, was sie bedrohen. Jeden Vorgang des Netzplans durchzugehen, ist Sache der Sensitivitätsanalyse.

Das Szenario in eine Änderung des Netzplans übersetzen

Der Netzplan ist das Modell, das die Vorgänge über ihre Abhängigkeiten verknüpft und aus dessen Berechnung die Termine hervorgehen. Die Übersetzung des Szenarios betrifft darin wenige Elemente: eine oder mehrere verlängerte Vorgangsdauern, eine hinzugefügte oder entfernte Abhängigkeit, ein verschobener Meilensteintermin, eine aus einer Periode herausgenommene Ressource.

Sonst ändert sich nichts. Der Basisplan ist der einzige verfügbare Vergleichspunkt, und ein Szenario, das die Gelegenheit nutzt, eine als falsch erkannte Dauer zu korrigieren, erzeugt eine Abweichung, bei der niemand mehr weiss, welcher Anteil vom Szenario stammt. Korrekturen am Modell erfolgen ausserhalb der Analyse, am Basisplan, und die Analyse setzt dort wieder an.

Den Netzplan neu berechnen

Der geänderte Netzplan durchläuft dieselbe Berechnung wie der ursprüngliche Terminplan: die Vorwärtsrechnung, welche die frühesten Termine vom Projektbeginn her fortschreibt, und die Rückwärtsrechnung, welche die spätesten Termine vom Projektende her zurückrechnet. Die Differenz zwischen beiden ergibt die Gesamtpufferzeit jedes Vorgangs, also die Verzögerung, die er aufnehmen kann, ohne den Endtermin des Projekts zu verschieben, zu unterscheiden von der freien Pufferzeit, der Verzögerung, die er aufnehmen kann, ohne den frühesten Anfang des Folgevorgangs zu verschieben. Der kritische Pfad ist die Folge von Vorgängen, deren Gesamtpufferzeit null ist.

Die Berechnung liefert zwei Ergebnisse, und das zweite geht leicht verloren. Das erste ist der neue Endtermin. Das zweite ist der neue kritische Pfad, der auf einen anderen Zweig des Netzplans wechseln kann, obwohl sich der Endtermin nicht bewegt hat. Dieser Wechsel ändert die Liste der Vorgänge, die für den Rest des Projekts zu überwachen sind, und eine auf den Endtermin beschränkte Lesart schliesst fälschlich, es sei nichts zu tun.

Zwei Modelleinstellungen verfälschen das Ergebnis, wenn man sie vergisst. Eine harte Terminvorgabe der Art "nicht vor einem bestimmten Datum beginnen" nimmt je nach ihrer Lage einen Teil der Verschiebung auf oder verstärkt sie. Eine aktive Ressourcennivellierung verteilt die Vorgänge bei jeder Neuberechnung um, sodass die beobachtete Abweichung die Wirkung des Szenarios und jene der Nivellierung vermischt. Beide Punkte werden am Basisplan geprüft, bevor das erste Szenario durchgespielt wird.

Mit dem Basisplan vergleichen

Was entscheidet, sind die Pufferzeit des betroffenen Vorgangs und seine Lage im Netzplan. Drei Wochen Verzögerung auf einem Vorgang mit vier Wochen Gesamtpufferzeit verschieben das Projektende nicht; acht Wochen auf einem Vorgang ohne Pufferzeit verschieben es um acht Wochen.

Die Pufferzeit ist eine gemeinsame Ressource, die das erste Szenario aufbraucht. Zwei einzeln aufgefangene Szenarien sind es zusammen nicht zwingend. Ihre Kumulation ist deshalb eine eigene Lesart, die als vollwertiges Szenario durchzuspielen ist, wenn die Bedingungen korreliert sind: Derselbe Streik bei einem Transportunternehmen verzögert oft mehrere Lieferungen. Die Addition der Einzelergebnisse ergibt diese Kumulation nicht, da die Pufferzeit nur einmal gezählt wird.

Entscheiden: Reserve und Massnahmenplan

Die Terminreserve wird nach den als plausibel beurteilten Szenarien bemessen. Sie alle zu addieren ergäbe einen Terminplan, den niemand finanziert. Die Wahl der abgedeckten Szenarien ist eine ausdrückliche Abwägung, die vor dem Auftraggeber begründet wird, und die Reserve bleibt unter der Kontrolle der Projektleitung, mit einer allen bekannten Freigaberegel. Eine Reserve, deren Herkunft nicht dokumentiert ist, wird als Erstes gestrichen, wenn der Terminplan unter Druck gerät.

Der Massnahmenplan betrifft die Szenarien, die den Endtermin nach hinten schieben würden. Er benennt die Handlung, ihre Auslösefrist und die Person, die entscheidet: zwei Arbeitspakete umstellen, zwei bisher sequenzielle Vorgänge überlappen lassen, eine Bestellung vor der erwarteten Freigabe auslösen, bei der zuständigen Behörde eskalieren. Ein von der Pufferzeit aufgefangenes Szenario verlangt weder Reserve noch Plan, doch die Pufferzeit, die es verbrauchen würde, wird festgehalten.

Der beim Projektstart beschriebene Netzplan existiert drei Monate später nicht mehr: Vorgänge sind abgeschlossen, Dauern haben sich geändert, die Pufferzeit hat sich verlagert und ein Szenario, das ohne Schaden durchging, geht nicht mehr durch. Die Analyse wird deshalb bei jeder Terminplanüberprüfung und nach jeder Änderung des kritischen Pfads erneut durchgespielt. Ist der erste Satz von Szenarien einmal geschrieben, kostet dieses erneute Durchspielen wenig.

Benanntes Szenario, Sensitivität, Simulation

Drei Instrumente arbeiten an der Unsicherheit eines Terminplans und beantworten drei verschiedene Fragen. Die Was-wäre-wenn-Szenarioanalyse spielt eine benannte Bedingung als Ganzes am Netzplan durch, um zu sehen, was hält und was bricht; sie ist deterministisch und liefert keine Wahrscheinlichkeit. Die Sensitivitätsanalyse ordnet nach Rang: Sie misst, welche Unsicherheitsquelle, für sich genommen, am stärksten mit dem Projektergebnis korreliert. Ihr Ergebnis lässt sich an einem Tornadodiagramm ablesen. Die Monte-Carlo-Simulation arbeitet mit Stichproben: Sie zieht eine grosse Zahl von Kombinationen der Vorgangsdauern aus Wahrscheinlichkeitsverteilungen und erzeugt eine Verteilung der Endtermine, aus der sich ein Konfidenzniveau für einen Zieltermin ablesen lässt.

Der PMBOK Guide trennt die drei in seinem Aufbau. Die Was-wäre-wenn-Szenarioanalyse ist ein Werkzeug der Terminplanungsprozesse selbst, das die planende Person an ihrem Netzplan durchspielt. Sensitivitätsanalyse und Simulation gehören zum Prozess der Risikoanalyse (§2.7.2.3) und speisen dessen quantitatives Modell. Der Terminplan erhält deren Ergebnisse von aussen. Die drei ergänzen sich: Die Sensitivität zeigt, wo hinzusehen ist, das Szenario beschreibt eine Bedingung, deren Durchspielen sich lohnt, die Simulation nennt den Termin, auf den man sich verpflichten kann.

Dieselbe Überlegung wird auch ausserhalb der Terminplanung angewendet. In der Geschäftsprozessanalyse wendet man eine benannte Bedingung auf die Parameter eines Prozesses an (Durchsatz, Kosten, Streuung), um dessen Reaktion zu beobachten, ohne Netzplan und ohne Endtermin (BPM CBOK §4.6.3).

KI-Überlegungen

Die Unterstützung betrifft Menge und Übersetzung. Ein Modell schlägt aus dem Risikoregister und der Historie vergleichbarer Projekte eine erste Liste möglicher Szenarien vor. Ein in Alltagssprache verfasstes Szenario übersetzt es in eine Änderung des Netzplans und benennt dabei den betroffenen Vorgang und das Ausmass. Die Reihe der Neuberechnungen führt es aus und formatiert die Vergleichstabelle. Auch die Deckungslücken findet es: die Vorgänge mit geringer Pufferzeit, die kein gewähltes Szenario berührt.

Das Urteil bleibt beim Menschen, wo die Analyse etwas verbindlich macht. Die Plausibilität eines Szenarios hängt vom Umfeld dieses Projekts, dieses Lieferanten, dieser Behörde, dieser Jahreszeit ab. Ein auf allgemeinen Daten trainiertes Modell erzeugt glaubwürdig klingende Bedingungen, die es in diesem Projekt nicht gibt. Die Bemessung der Reserve ist eine Verpflichtung gegenüber dem Auftraggeber und wird mit einer Begründung verteidigt. Ein Assistent, der von sich aus eine Ungereimtheit des Netzplans korrigiert, während er ein Szenario anwendet, entwertet den Vergleich, ohne dass etwas darauf hinweist. Die an einen gehosteten Dienst gesendete Anfrage trägt die Leistungsdaten der Lieferanten und die Konventionalstrafen des Vertrags aus der Organisation hinaus.

Beispiele

Erweiterung einer Abteilung für ambulante Chirurgie in einem Kantonsspital. Der Basisplan nennt den 15. Mai 2027 als Endtermin und sein kritischer Pfad führt über die Rechtskraft der Baubewilligung, die Vorbereitung des Baufelds, den Rohbau, die Haustechnik, die kantonale Sicherheitsinspektion und die Übergabe. Zwei Szenarien stammen aus dem Risikoregister und werden am Netzplan durchgespielt.

Visualisierungen

Ein Szenarienregister liefert die Ergebnisse, der Netzplan liefert den Mechanismus, der sie erzeugt. Den Basisplan und denselben Netzplan unter jedem der beiden Szenarien auf einer gemeinsamen Zeitachse übereinanderzulegen, macht den Weg sichtbar, auf dem sich eine Verzögerung ausbreitet: Wo der betroffene Vorgang auf dem kritischen Pfad liegt, erreicht die Verlängerung den Endmeilenstein und schiebt ihn um dasselbe Mass nach hinten; wo der Vorgang über Pufferzeit verfügt, endet sie innerhalb dieser Pufferzeit und der übrige Netzplan bewegt sich nicht.

Aufwand

Werkzeuge

Die Technik setzt ein Werkzeug voraus, das einen Netzplan führt und die Vorwärts- und die Rückwärtsrechnung ausführen kann: eine Projektterminplanungssoftware. Üblich ist es, die Datei des Basisplans je Szenario zu duplizieren. Werkzeuge mit einer Vergleichsfunktion zum Basisplan zeigen die Terminabweichung Vorgang für Vorgang an und ersparen dieses Hin und Her.

Eine Tabellenkalkulation trägt die Analyse für einen Netzplan von rund zehn Vorgängen; die von Hand gerechnete Rückwärtsrechnung ist dort die Stelle, an der sich die Fehler einschleichen. Bei grösseren Netzplänen ist die Terminplanungssoftware sicherer und schneller. Module für die Terminrisikoanalyse ergänzen am selben Netzplan die Simulation über Zufallsziehungen und das Tornadodiagramm, womit sich die drei Lesarten ohne erneute Erfassung des Modells durchführen lassen. Für die Formulierung der Szenarien ergeben ein Whiteboard und eine Stunde mit der Bauherrschaft, dem Generalunternehmer und der für die Bewilligungen zuständigen Person eine bessere Liste als jede Vorlage.

Quellen

• Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8. Aufl., PMI: die Was-wäre-wenn-Szenarioanalyse als Werkzeug der Datenanalyse bei der Erstellung (§2.3.2.2) und bei der Steuerung (§2.3.2.3) des Terminplans, die vom Szenario gestellte Frage, die Neuberechnung des Netzplans und die Verwendung des Ergebnisses für Reserven und Massnahmenpläne; die getrennten Definitionen von Sensitivitätsanalyse und Simulation (Abschnitt 5) und ihre Zuordnung zum Prozess der Risikoanalyse (§2.7.2.3), dessen quantitatives Modell sie speisen.
• U.S. Government Accountability Office, Schedule Assessment Guide: Best Practices for Project Schedules (GAO-16-89G), GAO: die Trennung innerhalb der Terminrisikoanalyse zwischen der Rangfolge der Variablen nach Korrelation und der iterativen Simulation, die eine Verteilung von Terminen erzeugt.
• ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §4.6.3: dieselbe Überlegung, angewandt auf die Parameter eines Geschäftsprozesses, ausserhalb des Terminplankontexts.