Annahmen- und Restriktionsanalyse

Ziel

Die Analyse prüft, ob der Plan eines Projekts auf Tatsachen beruht, die halten werden. Jedes Projekt entsteht auf der Grundlage von Annahmen und innerhalb von Restriktionen. Oft sind sie bereits in die Scope-Baseline und in die Schätzungen eingeflossen. Eine Schätzung von sechs Wochen für die Spezifikation setzt drei verfügbare Analysten voraus. Sind nur zwei verfügbar, ist der Terminplan seit seiner Unterzeichnung falsch.

Die Analyse zeigt, welche Annahmen zu Bedrohungen werden und welche Restriktionen das Team neu verhandeln kann. Das Risikoregister erhält eine Zeile je gefundene Bedrohung oder Chance. Auf dieser Grundlage schätzt das Team neu, verhandelt eine Restriktion mit dem Auftraggeber neu oder nimmt eine Grenze des Projekts hin.

Der PMBOK Guide nennt die Technik auch für die Planung des Stakeholder-Engagements. Das Team prüft dort auf dieselbe Weise seine Annahmen über die Verfügbarkeit oder die Unterstützung eines Stakeholders.

Einsatz

Wann einsetzen

• Unterzeichneter Projektauftrag oder Business Case: Die Annahmen des Auftrags vor dem Workshop zur Risikoidentifikation prüfen.
• Schätzung vor der Zusage: Unter jeder Zahl die Annahmen auflisten, bevor ein Budget oder ein Termin zugesagt wird.
• Phasenende: Die Annahmen der abgelaufenen Phase vor der Freigabe der nächsten überprüfen.
• Veränderter Kontext: Ein Gesetz in Revision oder ein ersetzter Lieferant öffnet die Annahmen wieder, die davon abhängen.
• Schnittstellen zu Drittsystemen: Prüfen, was das Projekt über die Daten, Formate und Fristen jedes Eigners annimmt.
• Plan für das Stakeholder-Engagement: Prüfen, was der Plan über ihre Verfügbarkeit und ihre Unterstützung annimmt.
• Auf mehrere Standorte verteiltes Team: Ein gemeinsames Protokoll genügt. Jeder Eigner prüft darin seine Annahmen ohne Sitzung.

Wann nicht einsetzen

• Bereits eingetretenes Ereignis: Es ist ein Problem. Es gehört ins Problemprotokoll, das Item Tracking führt.
• Suche nach neuen Ideen: Um eine Annahme umzukehren und Optionen zu erzeugen, zum kreativen Denken wechseln.
• Bezifferte Aussage, die an Daten zu prüfen ist: Die Hypothesenbildung und -prüfung entscheidet sie an einer Stichprobe.

Beschreibung

Annahme, Restriktion und Annahmenprotokoll

Der PMBOK Guide definiert die Annahme als einen Faktor im Planungsprozess, der ohne Beweis oder Nachweis als wahr, real oder sicher gilt. Die Restriktion ist ein begrenzender Faktor, der die Durchführung eines Portfolios, eines Programms, eines Projekts oder eines Prozesses beeinflusst. Diese Definition reicht über das Dreieck aus Termin, Kosten und Umfang hinaus. Ein Gesetz, ein Vertrag, eine technische Norm oder ein Entscheid des Auftraggebers sind Restriktionen.

Der BABOK Guide behandelt dasselbe Paar im Business Case. Er nennt Annahmen dort vereinbarte Tatsachen, die die Initiative beeinflussen können. Restriktionen schränken die Varianten ein. Laut BABOK Guide gewinnen die Stakeholder realistische Erwartungen und ein gemeinsames Verständnis, wenn sie diese Faktoren vereinbaren und dokumentieren. Eine vereinbarte Annahme bleibt im Sinne des PMBOK Guide unbewiesen. Mit der Vereinbarung übernehmen alle Stakeholder die Überzeugung, ohne sie zu prüfen.

Der PMBOK Guide beschreibt das Annahmenprotokoll als das Projektdokument, das alle Annahmen und alle Restriktionen festhält. Das Team trägt neue darin ein. Es aktualisiert den Status der bestehenden oder schliesst sie. Die strategischen und betrieblichen Restriktionen erscheinen vor dem Projektstart im Business Case und gehen dann in den Projektauftrag über. Die detaillierten Annahmen entstehen während des Projekts, wenn das Team die technischen Spezifikationen, die Schätzungen, die Aktivitäten des Terminplans und die Risiken erarbeitet.

Der Prozess "Projekt oder Phase starten" erzeugt das Protokoll. Die Prozesse der Planung, der Schätzung und des Risikomanagements lesen es und tragen ihre Aktualisierungen darin nach.

Im klassischen Vorgehen hält HERMES 2022 die Schätzungen mit ihrer Genauigkeit und ihren Reserven im Durchführungsauftrag und im Projektmanagementplan fest. HERMES verlangt, die Annahmen hinter diesen Schätzungen zu dokumentieren: Die Governance fordert diese Transparenz. HERMES definiert kein Annahmenprotokoll. Das Protokoll des PMBOK Guide erfüllt diese Anforderung.

Woher kommen Bedrohungen und Chancen?

Bedrohungen können aus ungenauen, instabilen, inkonsistenten oder unvollständigen Annahmen entstehen. Chancen können aus Restriktionen entstehen: Das Aufheben oder Lockern eines begrenzenden Faktors eröffnet einen Gewinn. Der Prozess "Risiken identifizieren" erkennt negative und positive Risiken.

Der PMBOK Guide definiert die Technik, ohne ihre Schritte anzugeben. Die Schritte 1 bis 5 wenden seine Definition der Reihe nach an.

1. Annahmen und Restriktionen sammeln

Das Team liest den Business Case, den Projektauftrag, die Scope-Baseline und die Schätzungsgrundlagen erneut. Es trägt jede Annahme und jede Restriktion mit ihrer Quelle und ihrem Eigner ins Protokoll ein. Viele Annahmen sind implizit. Eine Schätzung setzt ein Team, einen Liefertermin und einen Entscheidungsrhythmus voraus, die niemand aufgeschrieben hat. Die Analystin lässt sie sich im Interview von der Person nennen, die die Zahl erstellt hat. Die Dokumentenanalyse findet sie in Verträgen und Protokollen.

Die Analystin schreibt jede Annahme als prüfbare Tatsache: wer was tut, in welcher Menge, bis wann. "Die Benutzer werden verfügbar sein" lässt sich nicht prüfen. "Das Amt für Raumplanung stellt ab Februar zwei Personen an zwei Tagen pro Woche für die Abnahmetests (UAT) frei" lässt sich prüfen.

Das Protokoll trennt Annahmen von Restriktionen, weil das weitere Vorgehen verschieden ist. Eine Restriktion setzt jemand: der Auftraggeber, der Gesetzgeber, ein Vertrag. Eine Annahme hält das Team für wahr. Ein vom Auftraggeber angekündigter Termin gilt oft als Restriktion. Das Team fragt, woher er kommt. Ein Entscheid des Staatsrats ist eine Restriktion. Die Hoffnung eines Amtsvorstehers ist eine Annahme, die wie die anderen zu prüfen ist.

2. Jede Annahme prüfen

Der PMBOK Guide nennt die Mängel einer Annahme, ohne sie zu definieren. Jeder Mangel hat seine eigene Prüffrage. Die Fragen und die Beispiele für ein Scheitern sind eine Lesart aus der Praxis.

Die Analystin prüft bei der Quelle nach. Eine E-Mail an den Anbieter klärt die Frage schneller als eine Stunde Diskussion im Sitzungszimmer. Besteht eine Annahme die vier Tests, schliesst das Team sie im Protokoll und notiert ihre Quelle und das Datum der Prüfung. Eine Annahme, die einen Test nicht besteht, wird zu einer möglichen Bedrohung.

Die am wenigsten geprüfte Annahme ist oft die der ranghöchsten Person. Wer in der Sitzung den Termin des Auftraggebers bestreitet, braucht eine psychologische Sicherheit, die nicht jedes Team hat. Die Analystin fragt deshalb jeden Eigner schriftlich und Zeile für Zeile nach der Quelle.

3. Die Bedrohungen ins Register schreiben

Wie bei jeder Zeile des Registers formuliert das Team jede Bedrohung als Ursache, Ereignis und Auswirkung. Die Ursache ist der festgestellte Mangel. Das Ereignis: Die Annahme erweist sich als falsch. Die Auswirkung nennt das betroffene Ziel.

Die Annahme H-01 wird zur Bedrohung R-15: "Da eine schriftliche Zusage von Anbieter C fehlt, kann seine Schnittstellenspezifikation nach dem 30. September eintreffen, was den Integrationstest um sechs Wochen verzögern würde." Eine Kopie der Annahme im Register genügt nicht. "Der Anbieter liefert bis 30. September" beschreibt den Plan. Die Zeile im Register beschreibt das Ereignis, das dem Plan widerspricht. Die Bedrohung übernimmt das Datum der Annahme als Auslöser. Der Eigner von R-15 handelt, wenn die Spezifikation von Anbieter C am 30. September fehlt.

Die beiden Zeilen verweisen aufeinander. Bestätigt der Anbieter seinen Termin, schliesst das Team beide zusammen. Wahrscheinlichkeit und Auswirkung gehören zur Risikoanalyse und zur Wahrscheinlichkeits- und Auswirkungsmatrix. Das Team wählt die Reaktion mit den Risikoreaktionsstrategien.

4. Jede Restriktion hinterfragen

Zu jeder Restriktion stellt das Team eine Frage: Lässt sich die Grenze aufheben oder lockern? Nur die Person oder das Gremium, das eine Restriktion gesetzt hat, kann sie aufheben. Das Team hält deshalb fest, wer sie festgelegt hat und aus welchem Grund. Der Auftraggeber hat entschieden, dass alle Gemeinden am selben Tag umstellen, um zwei parallele Abläufe zu vermeiden. Darüber kann das Team mit ihm sprechen. Eine mit dem kantonalen Budget beschlossene Obergrenze bewegt sich vor dem nächsten Budget nicht.

Lautet die Antwort ja, schreibt das Team eine Chance ins Register: was das Projekt gewänne, wenn die Grenze fiele. Die Restriktion C-01 wird zur Chance R-19: "Da 9 Gemeinden die Pläne bereits als PDF erhalten, können sie das digitale Dossier drei Monate vor den anderen eröffnen, wenn der Auftraggeber den einheitlichen Termin lockert. Das ergäbe drei Monate Rückmeldungen aus der Nutzung vor der Einführung in den übrigen 12 Gemeinden." Die Chancenanalyse übernimmt. Lautet die Antwort nein, bleibt die Restriktion als Grenze des Projekts im Protokoll.

Ein Team, das alle Restriktionen als unantastbar behandelt, wendet die halbe Technik an.

5. Das Protokoll aktuell halten

Laut PMBOK Guide ist die Risikoidentifikation iterativ, weil manche Risiken erst im Projektverlauf auftauchen. Der Prozess "Risiken überwachen" aktualisiert auch das Annahmenprotokoll. Jede Zeile des Protokolls trägt den Status "offen" oder "geschlossen". Das Team geht das Protokoll bei jeder Risikoüberprüfung und an jedem Phasenende durch. Es ergänzt neue Annahmen, schliesst die bestätigten und prüft jene erneut, deren Kontext sich geändert hat.

Erweist sich eine Annahme als falsch, schliesst das Team ihre Zeile im Protokoll. Die Zeile im Register erhält den Status "eingetreten". Das Team eröffnet ein Problem im Problemprotokoll. Eine Annahme ohne Eigner und ohne Prüfdatum bleibt bis zum Projektabschluss offen. Niemand prüft sie. Beim Abschluss geht das Protokoll in die Lessons Learned ein: Die gefallenen Annahmen zeigen, was das nächste Projekt zuerst prüfen muss.

Benachbarte Techniken

Eine statistische Hypothese ist eine bezifferte Aussage. Die Hypothesenbildung und -prüfung stellt sie einer Datenstichprobe gegenüber. Die Analystin prüft die Planungsannahme bei ihrer Quelle: einem Anbieter, einem Amt, einem Vertrag.

Das kreative Denken kennt die Umkehrung von Annahmen. Es geht ebenfalls von einer Liste von Annahmen aus, kehrt jede um und diskutiert die Ideen, die aus der Umkehrung entstehen. Die Annahmen- und Restriktionsanalyse untersucht, ob eine Annahme halten wird und welches Risiko folgt, wenn sie fällt.

Der PMBOK Guide ordnet die Technik neben der SWOT-Analyse, der Ursachenanalyse, dem Brainstorming und den Checklisten dem Prozess "Risiken identifizieren" zu. Das Brainstorming gewinnt Risiken aus der Erfahrung der Teilnehmenden. Die Annahmen- und Restriktionsanalyse leitet sie aus dem Plan ab.

KI-Überlegungen

Ein Sprachmodell liest einen Projektauftrag, einen Business Case und die Schätzungsgrundlagen. Es zieht die impliziten Annahmen heraus: Verben im Futur, Termine ohne Quelle, als verfügbar vorausgesetzte Ressourcen. Es formuliert sie als prüfbare Tatsachen um und schlägt zu jeder die Fragen der vier Mängel vor. Es vergleicht die Dokumente und markiert Inkonsistenzen, zum Beispiel eine Zahl von Analysten, die zwischen Projektauftrag und Schätzung abweicht. Aus einer Annahme, die scheitert, formuliert es eine Bedrohung als Ursache, Ereignis und Auswirkung.

Das Modell weiss nicht, ob eine Annahme wahr ist. Es kennt weder die telefonische Zusage des Anbieters noch den künftigen Beschluss des Grossen Rates. Die Analystin prüft die Genauigkeit bei der Quelle und schätzt die Stabilität mit den Personen ein, die den Kontext kennen. Das Modell erzeugt auch plausible und generische Annahmen, die das Protokoll aufblähen. Eine vorgeschlagene Zeile kommt ins Protokoll, wenn ein Eigner sie anerkennt. Das Protokoll nennt Lieferanten, Personen und vertragliche Verpflichtungen. Es geht an einen externen KI-Dienst, wenn die Organisation das erlaubt. In einer Schweizer Verwaltung entscheiden das anwendbare Datenschutzrecht und der Speicherort.

Beispiele

Ein Westschweizer Kanton digitalisiert die Baugesuche. Das Team analysiert das Annahmenprotokoll am Ende der Initialisierung. Der Auszug zeigt das Protokoll nach der Analyse.

H-05 und C-02 erzeugen keine Zeile im Register. Das Team schliesst H-05 im Protokoll mit Quelle und Datum. C-02 bleibt offen, weil sie die Kosten bis zum nächsten Budget begrenzt. Ein analysiertes Protokoll behält diese Zeilen: Sie zeigen, was das Team geprüft hat und was es nicht neu verhandeln wollte.

Visualisierungen

Das Annahmenprotokoll ist eine Tabelle: eine Zeile je Annahme oder Restriktion mit Quelle, Analyseergebnis, erzeugter Registerzeile und Status. Ein Schema folgt den zwei Wegen der Technik: von den Annahmen zu den Bedrohungen und von den Restriktionen zu den Chancen. Ein zweites Schema zeigt die Status einer Protokollzeile bis zu ihrem Abschluss. Die Tabelle der Mängel gibt eine Frage je Mangel.

Aufwand

Werkzeuge

Für ein Protokoll mit einigen Dutzend Zeilen genügt eine Tabellenkalkulation: eine Spalte je geprüften Mangel, eine Auswahlliste für den Status ("offen", "geschlossen"), eine Spalte für den Verweis auf das Register. Ein Tracking-Tool wie Jira oder Azure DevOps führt Annahmen und Risiken als zwei verknüpfte Ticket-Typen. Es protokolliert jede Statusänderung und benachrichtigt den Eigner. Viele Teams führen ein einziges Protokoll für Risiken, Annahmen, Probleme und Abhängigkeiten. Man nennt es oft RAID-Log. Dieses Format hält die Zeile der Annahme und die Zeile der Bedrohung in derselben Datei. Für eine Schweizer Verwaltung bestimmt der Speicherort der Daten die Wahl, sobald das Protokoll Lieferanten oder Personen nennt.

Quellen

• Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8. Aufl., PMI: der Prozess "Risiken identifizieren" und seine Werkzeuge (§2.7.2.2, Abbildung 2-49); die Werkzeuge der Planung des Stakeholder-Engagements (§2.5.2.2, Abbildung 2-34); das Annahmenprotokoll (Section 4, Eintrag Assumption log); die Definition der Technik (Section 5, Eintrag Assumption and constraint analysis); die Definitionen von Annahme und Restriktion (Glossar).
• International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.7 Business Cases: das Element Assumptions, Risks, and Constraints.
• Bundeskanzlei, HERMES 2022, Referenzhandbuch Projektmanagement: die Annahmen hinter den Schätzungen (7.4.5.3 Planung der klassischen Lösungsentstehung, Abschnitt "Planungsgenauigkeit im Projektablauf").