Es scheitern zu viele (IT-)Grossprojekte, als dass es nur an unfähigen, überforderten Managern liegen kann. Ergo muss es auch damit zu tun haben, wie wir mit Risiken im Projektverlauf umgehen. Risikoidentifikation, -bewertung und Entscheidungsfindung sind die erfolgskritischen Elemente jedes Risikomanagementprozesses. Mit klaren Verantwortlichkeiten und einem trichterartigen, dreistufigen Selektionsprozess lassen sich Nebengeräusche von echten Risiken trennen. Die Komplexität grosser IT-Vorhaben lässt sich damit zwar nicht beherrschen, aber zumindest begrenzen.

Wie kann es sein, dass nicht nur im Vorfeld grosser Katastrophen, sondern auch bei den meisten IT-Debakeln zahlreiche Warnmeldungen eingehen, diese von den Verantwortlichen aber nicht oder zu wenig ernst genommen werden?

Die bequeme und naheliegende Erklärung ist, dass grosse IT-Projekte vor allem an unfähigen, überforderten Projekt- und Linienmanagern scheitern. Diese Erklärung greift jedoch zu kurz, denn dafür gibt es einfach zu viele Fehlschläge. Es muss also auch am System liegen, wie wir mit Projektrisiken umgehen. Der Elefant im Raum heisst deshalb Risikomanagement. Ein Beleg dafür ist auch die Kritik am mangelhaften Risikomanagement, die sich wie ein roter Faden durch viele Untersuchungsberichte zieht.

Eine wichtige Unterscheidung vorab: Risikomanagement ist nicht Krisenmanagement. Ab Ausbruch einer Krise sind die handelnden Personen wichtiger als Hierarchien und Prozesse. Bis zum Ausbruch der Krise ist es dagegen umgekehrt: Es braucht eine straffe Organisation mit effizienten Abläufen, damit sich im Ozean der Warnmeldungen wirklich relevante Signale erkennen lassen, sodass es gar nicht erst zur Krise kommt.

Es gilt daher, die Strukturen und Prozesse so aufzubauen, dass sich die wichtigsten Ziele eines Frühwarnsystems erreichen lassen: Potenzielle Problemherde erkennen, Indikatoren für problematische Entwicklungen definieren, Störereignisse bereits als schwache Signale erfassen und ihre Auswirkungen mit hinreichender Genauigkeit bewerten, damit sich den Entscheidungsträger eine klare Diagnose mit Szenarien und Handlungsoptionen unterbreiten lässt.

Zur Projektgovernance gehört in erster Linie der Projektausschuss mit den wichtigsten Stakeholdern und der Auftraggeberin an der Spitze. Der Projektausschuss soll – ähnlich dem Verwaltungsrat (VR) einer Aktiengesellschaft – sowohl strategische Entscheidungen fällen als auch die operative Leitung beaufsichtigen. Im Unterschied zum VR tragen die Mitglieder des Projektausschusses in der Regel keinerlei individuelle Verantwortung. Hermes, die obligatorische Vorgehensmethodik für Projekte der Öffentlichen Verwaltung, beschreibt den Projektausschuss als Gremium zur "Beratung und Unterstützung des Auftraggebers mit Empfehlungskompetenz".

Wenn aber allein die Auftraggeberin im Fall des Scheiterns zur Rechenschaft gezogen wird, besteht die Gefahr, dass ein "nur" beratendes Gremium zu ungerechtfertigtem Optimismus neigt oder bereit ist, übergrosse Risiken einzugehen. Deshalb braucht es wie bei VR-Gremien Unterausschüsse mit Verantwortung für die wichtigsten Belange der Projekttätigkeit, unter anderem dem Risikomanagement.

Der designierte Risikomanager als Leiter des Risk Committees ist dafür verantwortlich, die im Projektumfeld auftauchenden Gefahren frühzeitig zu identifizieren, eine unbeeinflusste, rationale Diagnose zu erstellen und mögliche Handlungsoptionen aufzuzeigen. Um seine Unabhängigkeit sicherzustellen und die Projektleitung vor Interessenkonflikten zu bewahren, kann und darf seine Rolle weder innerhalb der Projektorganisation angesiedelt sein noch darf er linienmässig der Auftraggeberin rapportieren. Damit die Verantwortlichkeiten nicht vermischt werden, darf er weder Handlungsempfehlungen abgeben noch darüber (mit-)entscheiden und schon gar nicht an der Umsetzung von Gegenmassnahmen beteiligt sein.

Der Risikomanager folgt einem mehrstufigen, trichterartigen Prozess, beginnend mit der Definition der Systemgrenze (s. Abb. 1).

Innerhalb dieser Grenze sind die direkt oder indirekt Beteiligten angesiedelt: Projektausschuss, Projektteam, Benutzerinnen und Benutzer, angrenzende IT-Systeme mit ihren Schnittstellen, Hard- und Softwarelieferanten sowie Consultingfirmen.

Ausserhalb der Systemgrenze befinden sich alle übrigen internen Stakeholder: typischerweise Stäbe, Audit, Procurement, IT-Sicherheit, Product Management oder HR. Gemeinsam bilden sie das Systemumfeld.

Gänzlich ausserhalb der Reichweite der Projektverantwortlichen sind die externen Einflussfaktoren und Rahmenbedingungen: Gesetze, Regulatorien, Medien, Konjunkturlage usw.

Abgeleitet aus den Systemgrenzen definiert der Risikomanager die im Laufe des Vorhabens auf Störgrössen zu überwachenden "Beobachtungsräume" oder "Risikozonen". Dazu gehören auch die Kernprozesse und -funktionen des neuen Systems.

Das Screening ist die erste Stufe der Risikoidentifikation und -bewertung. Ziel ist es, aktiv und wie ein Schwamm möglichst alle Risiken und Warnmeldungen aus den Beobachtungsräumen aufzunehmen. Nur selten handelt es sich dabei um klare, quantifizierbare Hinweise. Meistens sind es sogenannte weak signals, die sich im Projektverlauf vom kaum erkennbaren Punkt links unten auf dem Radarschirm in mehreren Stufen zur veritablen Gefahr für das Gesamtvorhaben entwickeln können.

Die bisher in den meisten IT-Projekten verwendete Matrix aus Eintrittswahrscheinlichkeit und Auswirkung eines Risikos lässt die dritte, für das Screening entscheidende Dimension der Signalstärke ausser Acht. Im Zentrum steht deshalb der dreidimensionale Risikowürfel mit den Dimensionen Signalstärke, Dringlichkeit und Relevanz/Auswirkungen (s. Abb. 2).

Bei der Dimension Signalstärke wird mit den drei Stufen "Gerücht/Ahnung", "Fundierte Annahme" und "Klarheit/Fakt" die Zuverlässigkeit der Quelle und die Qualität eines Warnhinweises überprüft.

Die Dimension Dringlichkeit enthält die Abstufungen tief, mittel und dringend. Dabei wird vom Zieldatum, das heisst der Projekteinführung aus zurückgerechnet. Der Risikomanager wird den drei Abstufungen entsprechende Fristen zuordnen. Die Standardfrage hierzu lautet: In welchem Zeitraum kann das Risiko eintreffen?

Die dritte Dimension "Auswirkungen" mit der Abstufung marginal, moderat und gravierend gibt Aufschluss über das Ausmass des maximalen Schadens. "Gravierend" bedeutet, dass das Projekt als Ganzes scheitern kann, falls das Risiko ohne Gegenmassnahmen eintritt.

Dem 80/20-Pareto-Prinzip folgend, wird der Risikomanager nicht mehr als 20% aller identifizierten Risiken an die nächste Prozessstufe Monitoring übergeben.

In dieser Phase geht es darum, die aus dem Screening übernommenen Risiken einer individuellen Tiefenanalyse zu unterziehen.

Den Kern des Monitorings bildet dabei die Risikomatrix mit den Kategorien Eintrittswahrscheinlichkeit und Beeinflussbarkeit des Risikos. Falls ein Risiko beeinflussbar ist, sind ab einem "möglichen" Eintritt zwingend Gegenmassnahmen zur Risikovermeidung vorzubereiten (s. Abb. 3).

Ist ein Risiko nicht oder höchstens indirekt beeinflussbar, gibt es nur die Möglichkeit prophylaktischer Massnahmen zur Risikominderung. Bei gänzlich fehlender Lenkbarkeit, kombiniert mit tiefer Eintrittswahrscheinlichkeit, kann die Situation als Restrisiko akzeptiert und selbst getragen werden.

Bei unwahrscheinlichen Risiken, die sich nur indirekt beeinflussen lassen, ist eine mögliche Risikoüberwälzung an Dritte zu prüfen.

Als Nächstes gilt es, die schwierige Hürde stufengerechter Kommunikation gegenüber den Entscheidungsträgern zu überwinden und damit die notwendige management attention sicherzustellen.

Es gehört zum Pflichtenheft des Risikomanagers, den Risikokatalog regelmässig zu aktualisieren und die nüchterne Diagnose des Risiko- und Gefahrenbildes stufengerecht zu kommunizieren. In Bezug auf den Adressatenkreis gilt, dass Stillschweigen als explizites Einverständnis zur Risikodiagnose, der Beurteilung sowie den aufgezeigten Handlungsoptionen interpretiert wird.

IT-Grossprojekte sind komplexe Vorhaben. Deshalb liegt die Gefahr des Scheiterns in der Natur der Sache. Weil sich gut geführte Unternehmen unter anderem daran erkennen lassen, wie rasch schlechte Nachrichten nach oben gelangen, geht bei Status "Rot" automatisch eine Kopie des Risikoberichtes an die zuständige Hierarchiestufe im ober(st)en Management. Dadurch lässt sich wertvolle Zeit für "Unterstützung von oben" gewinnen und ausserdem sicherstellen, dass sich die höchsten Entscheidungsträger später nicht auf Unwissen berufen können.

Der Risikomanager wird seine Diagnose, die Szenarien und Handlungsoptionen dem Projektausschuss präsentieren, muss allerdings bei einer Abstimmung in den Ausstand treten, um seine Unabhängigkeit zu bewahren.

… dann kommt es irgendwann zu dir." IT-Debakel fallen nicht über Nacht vom Himmel, sondern kündigen sich lange vor Ausbruch der Krise durch schwache Signale und Warnhinweise an. Die Crux dabei: Je früher auf Risiken aufmerksam gemacht wird, desto lückenhafter sind die Informationen und desto grösser das Risiko von Fehlalarmen. Je mehr Fehlalarme, desto geringer nicht nur die Glaubwürdigkeit, sondern früher oder später auch die Achtsamkeit.

Demgegenüber ist es bei komplexen Vorhaben mit ihren verstärkenden beziehungsweise kompensierenden Rückkopplungen unmöglich, alle Risiken zum vorne herein und detailliert zu erfassen.

Die Anforderungen an den Risikomanager sind deshalb hoch. Im Projektausschuss wird es aus unterschiedlichen Gründen Zweifel am Gefährdungsgrad der aufgezeigten Risiken geben. Der Prozess muss deshalb systematisch und transparent sein. Der Risikomanager als Person muss darüber hinaus nicht nur verantwortungsbewusst, sondern auch standfest gegenüber persönlichen Angriffen sein ("shoot the messenger").

Selbstverständlich gilt es, den Risikomanagementprozess nicht nur regelmässig zu wiederholen, sondern die dabei gemachten Erfahrungen auch zu dokumentieren und im Sinne der "lernenden Organisation" auch in die Aus- und Weiterbildung von ProjektleiterInnen und Projektausschussmitgliedern einfliessen zu lassen.

Ein Schlusswort noch zu KI und der unvermeidlichen Frage, ob Risikomanagement im Zeitalter künstlicher Intelligenz noch nötig ist. Die beruhigende Antwort dazu liefert das bekannte "unknown unknowns"-Zitat von Donald Rumsfeld (ehemaliger US-Verteidigungsminister) aus dem Jahr 2002: "[…] es gibt auch unbekannte Unbekannte – Dinge, von denen wir nicht wissen, dass wir sie nicht wissen. Und wenn man sich die Geschichte […] anschaut, dann ist es diese Kategorie, die am schwierigsten zu lösen ist." Davon scheint die IT-Technologie noch weit entfernt zu sein.