Am Dienstagmorgen meldet sich Ihr Produktmanager: Der geplante Veröffentlichungstermin ist gefährdet. Bis zur Mittagspause berichtet der Integrationsverantwortliche, dass der Anbieter seine API geändert hat und das Team Nachbesserungen vornehmen muss. Am späten Nachmittag fragt die Qualitätssicherung (QA), welche Tests gestrichen werden sollen, da der Zeitplan plötzlich gestrafft wurde. Der Sicherheitsanalyst ergänzt, dass das verkürzte Testfenster wahrscheinlich dazu führen wird, dass Sicherheitsbefunde erst nach dem Code-Freeze vorliegen. Sie sind der Projektmanager und stehen vor der schwierigen Entscheidung: den Projektumfang beibehalten, den Termin verschieben oder Qualitätseinbußen in Kauf nehmen? Mit jeder Stunde des Zögerns steigen die Kosten für die letztendliche Entscheidung, da die Teams weiterhin auf der Basis unterschiedlicher Annahmen arbeiten.
Bevor Sie eine Statusfolie erstellen, müssen Sie eine klare Unterscheidung treffen. Ein Risiko ist ein ungewisses zukünftiges Ereignis, das sich auf die Projektziele auswirken könnte. Ein Problem (oder „Issue“) ist ein aktueller Sachverhalt, der bereits eingetreten ist. Die Änderung der Anbieter-API ist ein Problem, sobald sie tatsächlich stattfindet; die bloße Möglichkeit, dass sie eintreten könnte, war zuvor ein Risiko. Dieser Kurs vermittelt Ihnen das Urteilsvermögen und die Werkzeuge, um diese Unterscheidung klar und praxisnah zu handhaben. Dabei kommen ein funktionierendes Risikoregister, eine einseitige Zusammenfassung von Zielen und Risikobereitschaft, präzise Risikoformulierungen mit Auslösern (Triggern) sowie ein schlankes Monitoring zum Einsatz, damit Ungewissheiten früh genug erkannt werden, um handeln zu können.
Gehen Sie zur Einstimmung den Ablauf der Ereignisse durch und markieren Sie den Punkt, an dem das Projekt von der Phase der Ungewissheit in die Realität überging.
Wenn Teams darüber streiten, ob ein Risiko eine Nachverfolgung wert ist, geht es oft eigentlich um etwas anderes. Sie streiten darüber, worauf das Projekt optimiert werden soll, welche Annahmen gelten dürfen und welche Rahmenbedingungen unverrückbar sind. Sind diese Punkte unklar, enden alle Diskussionen über Risiken mit vagen Ratschlägen wie „Behaltet das mal im Auge“.
Ein praxisnaher Rahmen passt auf eine Seite und beginnt mit den Zielen. Ein Zeitplan-Ziel könnte die Auslieferung bis Quartalsende sein. Ein Kostenziel könnte die Einhaltung eines festen Budgets für einen externen Anbieter sein. Ein Qualitätsziel könnte lauten: keine kritischen Sicherheitslücken zum Zeitpunkt der Einführung. Darauf aufbauend listen Sie Annahmen auf, die Sie der Planung zugrunde legen (z. B. dass die API des Anbieters abwärtskompatibel bleibt), sowie Rahmenbedingungen, die nicht verhandelbar sind (z. B. eine behördliche Frist). Anschließend legen Sie die Risikobereitschaft fest: Welches Maß an Abweichung toleriert der Auftraggeber, bevor er eine Eskalation und eine Entscheidung erwartet? Risikobereitschaft ist nicht gleichbedeutend mit Optimismus. Sie bildet den Handlungsspielraum ab.
Ein häufiger Fehler: Der falsche Instinkt führt dazu, eine pauschale Vorgabe zu machen, etwa „Wir gehen nur geringe Risiken ein“. Das wirkt zwar entschlossen, führt aber zu verdeckten Kompromissen: Das Team sichert den Zeitplan, indem es Tests ohne Zustimmung des Auftraggebers streicht, oder es wahrt die Qualität, indem es den Termin verschiebt, ohne den Vertrieb zu informieren.
Wählen Sie die Risikobereitschaft passend zum Projektkontext, nicht nach persönlichen Vorlieben.