Worum geht es bei der Risikoidentifikation?
ISO 31000 beschreibt den Zweck der Risikoidentifikation darin, Risiken zu finden, zu erkennen und zu beschreiben, die einer Organisation helfen oder sie daran hindern können, ihre Ziele zu erreichen; relevante, angemessene und aktuelle Informationen sind dafür wichtig [1]. Im Projekt heisst das: Gesucht werden alle Unsicherheiten, die Termine, Kosten, Umfang, Qualität oder Nutzen beeinflussen können, und zwar unabhängig davon, ob ihre Ursachen im Einflussbereich des Projekts liegen.
Die Norm nennt eine Reihe von Faktoren, die bei der Identifikation zu berücksichtigen sind, darunter greifbare und nicht greifbare Risikoquellen, Ursachen und Ereignisse, Bedrohungen und Chancen, Schwachstellen und Fähigkeiten, Veränderungen im Umfeld, Indikatoren neu entstehender Risiken, Grenzen des Wissens und der Verlässlichkeit von Informationen, zeitliche Faktoren sowie Voreingenommenheit, Annahmen und Überzeugungen der Beteiligten [1]. Der letzte Punkt ist besonders wichtig: Teams übersehen Risiken oft nicht aus Unwissen, sondern weil Optimismus oder Gruppendruck sie ausblenden.
Wie beschreibt man ein Risiko richtig?
Viele Risikoregister enthalten Einträge wie «Lieferant», «Budget» oder «Personal». Das sind Themen, keine Risiken, und daraus lassen sich keine Massnahmen ableiten. Bewährt hat sich ein dreiteiliges Format: «Aufgrund von Ursache kann Ereignis eintreten, was zu Auswirkung führt.» Die Ursache ist eine Tatsache oder Gegebenheit, das Ereignis ist unsicher, die Auswirkung betrifft die Projektziele. Diese Struktur entspricht der Beschreibung von Risiko über Risikoquellen, Ereignisse und Konsequenzen in ISO 31000.
| Schwach | Gut |
|---|---|
| Lieferant | Aufgrund der Kapazitätsengpässe beim Schnittstellenlieferanten kann sich die Lieferung um bis zu drei Wochen verzögern, was den Livegang verschiebt und Mehrkosten verursacht. |
| Personal | Weil das Wissen über das Altsystem bei einer einzigen Person liegt, kann deren Ausfall die Datenmigration blockieren und zu einer Verschiebung von vier Wochen führen. |
| Anforderungen | Da der Fachbereich das Zielbild noch nicht verabschiedet hat, können sich Anforderungen nach Umsetzungsbeginn ändern, was Nacharbeit von bis zu 20 Personentagen verursacht. |
| Budget | Wegen steigender Lizenzpreise des Anbieters können die Betriebskosten im ersten Jahr um bis zu 12 000 CHF über dem Plan liegen. |
Welche Techniken zur Risikoidentifikation gibt es?
| Technik | Vorgehen | Stärke | Grenze |
|---|---|---|---|
| Risikoworkshop | Team sammelt Risiken strukturiert nach Kategorien | breite Sicht, gemeinsames Verständnis | Gruppendruck, dominante Personen |
| Checklisten | Risikolisten aus früheren Projekten durchgehen | schnell, nichts Bekanntes vergessen | neue Risiken bleiben verborgen |
| Annahmen- und Abhängigkeitsanalyse | jede Annahme und Abhängigkeit im Plan hinterfragen | findet versteckte Risiken im Plan | braucht einen ausgearbeiteten Plan |
| Experteninterviews | Fachleute einzeln befragen | Tiefe, heikle Themen | zeitaufwendig |
| Pre-Mortem | Team stellt sich das Scheitern vor und sucht Gründe | überwindet Optimismus und Gruppendruck | braucht gute Moderation |
| SWOT-Analyse | Stärken, Schwächen, Chancen, Bedrohungen | verbindet Risiken und Chancen | eher grob |
| Lessons Learned | Abschlussberichte ähnlicher Projekte auswerten | nutzt Erfahrung der Organisation | nur so gut wie die Dokumentation |
Eine Übersicht über Risikobeurteilungsverfahren, von Brainstorming über strukturierte Interviews bis zu Szenarioanalysen, bietet die Norm IEC 31010:2019 [2]. Für Projekte hat sich die Kombination aus Workshop, Annahmenanalyse und Lessons Learned bewährt; das Pre-Mortem ergänzt sie wirksam, wenn das Team zu optimistisch wirkt. Eine Vorlage für die Analyse bietet flenio.ch unter SWOT-Analyse.
Wie funktioniert ein Pre-Mortem?
- 1Einleitung: Die moderierende Person bittet das Team, sich vorzustellen, das Projekt sei ein Jahr später gescheitert.
- 2Stille Phase: Jede Person schreibt in zehn Minuten alle Gründe auf, die zum Scheitern geführt haben könnten.
- 3Sammeln: Reihum wird je ein Grund genannt, bis alle erfasst sind.
- 4Gruppieren: Ähnliche Gründe werden zusammengefasst.
- 5Bewerten: Das Team markiert die wahrscheinlichsten und folgenreichsten Gründe.
- 6Übertragen: Die wichtigsten Gründe werden als Risiken mit Ursache, Ereignis und Auswirkung ins Register aufgenommen.
Der Vorteil des Pre-Mortem liegt in der Perspektive: Wer annimmt, das Scheitern sei bereits eingetreten, muss es nicht mehr als unwahrscheinlich verteidigen, sondern nur noch erklären. Dadurch werden Risiken ausgesprochen, die in einem klassischen Workshop als zu pessimistisch gelten würden, etwa fehlende Unterstützung durch das Management oder ein unrealistischer Termin.
Welche Risikokategorien gibt es im Projekt?
| Kategorie | Typische Risiken |
|---|---|
| Anforderungen und Umfang | unklare Ziele, Änderungen nach Umsetzungsbeginn, schleichende Ausweitung |
| Technik | neue Technologie, Schnittstellen, Leistung, Datenmigration, Sicherheit |
| Personal | Ausfall von Schlüsselpersonen, fehlende Kompetenzen, Überlastung |
| Organisation | fehlende Unterstützung durch Management, parallele Projekte, Reorganisation |
| Lieferanten und Partner | Verzug, Qualitätsmängel, Insolvenz, Preissteigerungen |
| Recht und Compliance | Datenschutz, Vergaberecht, Verträge, neue Vorschriften |
| Finanzen | Budgetkürzung, Kostenüberschreitung, Wechselkurse |
| Umfeld und Akzeptanz | Widerstand der Nutzenden, politische Veränderungen, Marktveränderungen |
Kategorien dienen als Gedankenstütze im Workshop: Für jede Kategorie wird gefragt, welche Risiken in diesem Projekt bestehen. So wird verhindert, dass sich die Diskussion nur um technische Fragen dreht, während organisatorische Risiken wie fehlende Verfügbarkeit des Fachbereichs übersehen werden. Erfahrungsgemäss gehören Anforderungen, Personal und Organisation zu den häufigsten Ursachen für Probleme in Projekten.
Beispiel: Risikoworkshop für eine Softwareeinführung
Eine Kanzlei führt eine neue Mandatsverwaltung ein. Im Risikoworkshop mit Projektleitung, zwei Anwältinnen, der Leitung Sekretariat und dem Informatikpartner werden in 90 Minuten 23 Risiken gesammelt und zu 14 zusammengefasst. Die wichtigsten: Die Migration alter Akten ist aufwendiger als geschätzt, weil Daten unvollständig sind; die Anwältinnen haben während der Einführung wegen laufender Verfahren kaum Zeit für Schulungen; der Anbieter hat in der Schweiz nur einen Supportmitarbeitenden; die Konfliktprüfung im neuen System funktioniert anders als bisher. Eine Annahmenanalyse des Terminplans ergänzt ein weiteres Risiko: Der Plan setzt voraus, dass die Kanzlei im August, während der Ferien, Tests durchführt.
Jedes Risiko wird mit Ursache, Ereignis und Auswirkung beschrieben, einem Eigner zugeordnet und anschliessend bewertet. Wie die Bewertung erfolgt, beschreibt der Beitrag Risikobewertung; welche Strategien danach zur Wahl stehen, der Beitrag Risikostrategien.
Wann werden Risiken identifiziert?
Risiken werden nicht nur zu Projektbeginn identifiziert. Bewährt sind feste Zeitpunkte: bei der Projektinitialisierung, vor jedem Meilenstein oder jeder Phasenfreigabe, bei grösseren Änderungen im Umfang oder Umfeld und in regelmässigen Abständen, etwa monatlich oder pro Sprint. Neue Risiken entstehen im Projektverlauf ständig: Ein Lieferant wechselt den Ansprechpartner, eine Schlüsselperson kündigt, eine Vorschrift ändert sich. ISO 31000 betont den dynamischen Charakter des Risikomanagements, das Veränderungen erkennt und angemessen darauf reagiert [1]. Auch ISO 21502 behandelt Risikomanagement als laufende Praxis über die gesamte Projektdauer [3].
Typische Fehler bei der Risikoidentifikation
| Fehler | Folge | Gegenmittel |
|---|---|---|
| Themen statt Risiken | keine Massnahmen ableitbar | Format Ursache, Ereignis, Auswirkung |
| Nur Projektleitung sammelt | einseitige Sicht | Team, Fachbereich und Partner einbeziehen |
| Nur einmal zu Projektbeginn | neue Risiken bleiben unentdeckt | feste Zeitpunkte im Projektverlauf |
| Unbequeme Risiken verschwiegen | Überraschungen im Projekt | Pre-Mortem, anonyme Sammlung |
| Nur Bedrohungen gesammelt | Chancen bleiben ungenutzt | ausdrücklich nach Chancen fragen |
Risiken im Werkzeug erfassen
Identifizierte Risiken gehören in ein zentrales Register, auf das alle Projektbeteiligten Zugriff haben. Vorlagen bietet flenio.ch unter Risikoregister; das Glossar erklärt den Begriff unter Risikoregister. In Flenio lassen sich Risiken mit Eigner, Status und Massnahmen als Aufgaben erfassen und im Projektstatus sichtbar machen. Wie Risiken in den Statusbericht einfliessen, beschreibt der Beitrag Projektstatus objektiv bewerten. Den Gesamtzusammenhang zeigt der Leitfaden Risikomanagement im Projekt.
Wie findet man Risiken in Annahmen und Abhängigkeiten?
Jeder Projektplan beruht auf Annahmen: dass Personen verfügbar sind, dass Lieferanten pünktlich liefern, dass Anforderungen stabil bleiben, dass Systeme wie erwartet funktionieren. Jede dieser Annahmen ist eine mögliche Risikoquelle. Eine systematische Annahmenanalyse geht den Plan Schritt für Schritt durch und fragt bei jedem Arbeitspaket: Was muss gegeben sein, damit dieses Paket wie geplant gelingt? Wie sicher ist das? Was passiert, wenn es nicht zutrifft? Ähnlich wird bei Abhängigkeiten vorgegangen: Jede Abhängigkeit von einem anderen Team, Projekt oder Lieferanten wird auf ihre Verlässlichkeit geprüft. So entstehen Risiken, die direkt mit dem Plan verbunden sind und sich gezielt behandeln lassen, etwa durch Puffer an kritischen Übergängen.
Die Ergebnisse einer solchen Analyse fliessen direkt in die Risikobewertung und in die Terminplanung ein, etwa als zusätzliche Puffer an Übergängen zu externen Partnern oder als vorgezogene Prüfungen kritischer Annahmen.
Für wiederkehrende Projekttypen lohnt sich zudem eine eigene Checkliste typischer Risiken, die nach jedem Projekt mit den Erfahrungen ergänzt wird. So wächst das Wissen der Organisation von Projekt zu Projekt.
Gute Identifikation ist damit weniger eine Frage der Methode als der Regelmässigkeit und der Offenheit im Team: Wer Risiken früh und ohne Schuldzuweisung ansprechen kann, liefert die wertvollsten Hinweise. Projektleitende fördern diese Offenheit, indem sie selbst Unsicherheiten benennen.
Das schafft Vertrauen und erleichtert es allen Beteiligten, Bedenken frühzeitig zu äussern.