Im Projektplan für eine kommunale Systemmigration steht viermal das Wort ‚sobald‘: sobald der Lieferant liefert, sobald die Nutzer geschult sind, sobald sich die Gesetzgebung nicht ändert. Niemand hat je laut gefragt, was passiert, wenn eines dieser ‚Sobalds‘ nicht eintrifft — bis der Lieferant sich als fünf Monate zu spät herausstellt. Unter jedem Projektplan liegt eine solche Ansammlung von Annahmen: dass der Lieferant pünktlich liefert, dass die Nutzer mitziehen, dass die Technik hält, was die Broschüre verspricht, dass die Organisation den Wandel verkraftet. Die Frage ist nie, ob ein Plan auf Annahmen ruht, sondern ob diese Annahmen aufgeschrieben oder stillschweigend eingeschlichen sind. Und stillschweigende Annahmen sind die gefährlichsten, weil man ein Risiko, das man nicht benennt, auch nicht beherrschen kann.
Die Kernfrage
Es gibt eine Frage, die die Qualität eines Plans offenlegt: Was alles muss wahr sein, damit dieser Plan aufgeht? Wer diese Frage ernsthaft stellt, entdeckt oft eine lange Liste von Bedingungen, die der Plan als selbstverständlich behandelt. Jede Bedingung, die wahr sein muss, aber nicht sicher ist, ist eine Annahme. Und jede Annahme ist eine potenzielle Bruchstelle.
Annahmen sind der Angelpunkt zwischen Optimismus und Prüfbarkeit. Solange sie implizit bleiben, kann ein Plan so optimistisch sein, wie er will, ohne dass jemand es kontrollieren kann. Sobald sie ausdrücklich auf dem Papier stehen, wird jeder Optimismus plötzlich überprüfbar: Stimmt diese Annahme eigentlich? Worauf beruht sie? Was passiert, wenn sie sich als unwahr herausstellt?
Annahmen machen Optimismus prüfbar
Dies ist die direkte Brücke zur Bias-Literatur. Schätzungen und Planungen sind systematisch zu optimistisch — nicht aus Unwillen, sondern weil Menschen von Natur aus den günstigen Verlauf voraussetzen. Optimismus lässt sich jedoch nicht mit dem Aufruf "sei mal realistischer" bekämpfen. Er lässt sich bekämpfen, indem man die Voraussetzungen, auf denen der Optimismus ruht, eine nach der anderen sichtbar macht.
Nehmen Sie eine Schätzung, die von der vollständigen Verfügbarkeit eines knappen Teams ausgeht. Solange diese Annahme implizit ist, sieht die Planung straff und machbar aus. Sobald man aufschreibt "dieser Plan geht davon aus, dass die drei Senior-Spezialisten sechs Monate lang zu 100 Prozent verfügbar sind", sieht man sofort, wie fragil er ist. Die Annahme explizit zu machen, tut dem Optimismus keine Gewalt an — es macht ihn besprechbar.
Eine Annahme, die man aufschreibt, kann man prüfen. Eine Annahme, die man verschweigt, prüft sich selbst — im denkbar schlechtesten Moment.
Von der Annahme zum Risiko
Sobald Annahmen explizit sind, werden sie für das Risikomanagement nutzbar. Jede Annahme trägt nämlich ein Risiko in sich: das Risiko, dass sie nicht wahr ist. Ein guter Projektplan koppelt die beiden ausdrücklich aneinander — für jede kritische Annahme: Wie wahrscheinlich ist es, dass sie zutrifft, und welche Auswirkung hat es, wenn sie nicht zutrifft?
Williams und Kollegen stellen die Risikoeinschätzung nachdrücklich in den Kern der Quality-at-Entry — sie ist ein fester Bestandteil der Front-End-Beurteilung. Das Adviescollege ICT-toetsing nennt "Risikobeherrschung und Projektabhängigkeiten" als eines seiner Risikogebiete. Diese Abhängigkeiten sind nichts anderes als Annahmen über andere Parteien: dass sie liefern, mitwirken oder ihren Teil rechtzeitig fertig haben.
Die Annahmen, die am meisten verschwiegen werden
Manche Annahmen werden fast nie aufgeschrieben, gerade weil sie so bequem sind:
- Verhaltensannahmen: dass die Nutzer das neue System tatsächlich verwenden werden, dass die Mitarbeitenden die Veränderung annehmen.
- Kapazitätsannahmen: dass die Organisation dieses Projekt neben der regulären Arbeit bewältigt.
- Externe Annahmen: dass sich Gesetze und Regulierung, Markt oder Lieferanten während der Laufzeit nicht verändern.
- Wissensannahmen: dass das Team weiß, was es über die Komplexität der Aufgabe zu wissen glaubt.
Das sind genau die Annahmen, die im Nachhinein, bei der Evaluierung eines gescheiterten Projekts, als "unvorhergesehene Umstände" angeführt werden. Sie waren selten unvorhergesehen — sie waren unbenannt.
Prüfbar, nicht vollständig
Eine Einschränkung: Das Ziel ist keine erschöpfende Liste jeder denkbaren Annahme. Das versandet in einem unlesbaren Dokument, in dem die kritischen Annahmen zwischen den trivialen untergehen. Es geht um die Annahmen, die wesentlich sind — die den Plan ins Wanken bringen, wenn sie sich als unwahr herausstellen.
Der Test ist einfach: Würde sich der Plan grundlegend ändern, wenn diese Annahme nicht zuträfe? Wenn ja, dann gehört sie ausdrücklich in den Plan, mit einer Einschätzung von Wahrscheinlichkeit und Auswirkung. Wenn nein, dann darf sie implizit bleiben.
Was das für Sie bedeutet
Nehmen Sie den Projektplan, der gerade auf Ihrem Schreibtisch liegt, und stellen Sie zur wichtigsten Annahme eine Frage laut: Was passiert, wenn sich das als nicht wahr herausstellt? Schreiben Sie die Antwort in den Plan selbst, mit einer Einschätzung von Wahrscheinlichkeit und Auswirkung — nicht nur im Kopf, wo es wieder still wird.
Ein Plan, der seine Annahmen benennt, kennt seine eigene Schwachstelle. Ein Plan, der sie verschweigt, entdeckt sie erst, wenn es zu spät ist.
Quellen
- Williams, T., Vo, H., Samset, K. & Edkins, A. (2019), The front-end of projects: a systematic literature review, Production Planning & Control.
- Adviescollege ICT-toetsing, Toetskader (risicogebied "Risicobeheersing en projectafhankelijkheden").