Risikomanagement im Projektgeschäft setzt sich zusammen aus einer initialen Beurteilung einerseits und der laufenden Überwachung auftauchender und sich möglicherweise zu Problemen entwickelnden Gefahren andererseits. Meine letzte Kolumne hat sich mit der initialen Beurteilung von Projektrisiken befasst. Im aktuellen Beitrag beleuchte ich deshalb das bisher stiefmütterlich behandelte Thema der laufenden Risikobewirtschaftung.

Unabhängig davon, ob eine agile oder die Wasserfall-Vorgehensmethodik gewählt wird, sind IT-Projekte per definitionem einmalige und deshalb auch erstmalige Vorhaben. Deshalb ist die Wahrscheinlichkeit gross, dass Projektleiterinnen und Projektleiter mit Hindernissen konfrontiert sein werden, die sie vorher noch nie angetroffen haben. Eine Vielzahl an menschlichen und technischen Interaktionen und Rückkopplungen sorgen für eine Komplexität, die schwierig – wenn überhaupt – zu beherrschen ist.

Die heute praktizierte Aufsicht und Kontrolle sowie das Risikomanagement zielen in erster Linie auf interne Gefahren. Mithilfe engmaschiger Kontrollnetze aus Termin-, Kosten- und Statusreports hat das Management diese Risiken relativ gut im Griff.

Nach meiner Erfahrung haben allerdings die echten Gefahren für grosse IT-Vorhaben ihre Quelle häufig ausserhalb des Projektes: typischerweise bei Schnittstellen, Lieferanten, Anforderungs-/Gesetzesänderungen oder Budgetkürzungen etc.

Seien wir ehrlich: Das herkömmliche Risikomanagement für Grossprojekte mit der dreistufigen tief/mittel/hoch-Matrix aus Wahrscheinlichkeit und Auswirkung ist eine "Alibiübung" für den Steuerungsausschuss und die übrigen Stakeholder. Die Projektleitung kostet es höchstens eine Stunde Aufwand vor dem Steuerungsausschuss-Meeting, den entsprechenden Standard-Slide mit generischen Risiko-Bubbles zu befüllen und sich dazu ein paar ebenso generische Gegenmassnahmen (Mitigation) zu überlegen.

Externe Einflüsse und Risiken hingegen, die zuerst fast unbemerkt auf dem Radarschirm erscheinen und deshalb (zu) lange unbemerkt bleiben, können sich über die Zeit zu echten Problemen entwickeln und bei fortdauernder Missachtung sogar das ganze Projekt gefährden. Ein selbst erlebtes Beispiel aus einem meiner letzten Mandate als Co-Projektleiter für ein grosses Finanzinstitut mag dies illustrieren (siehe Kasten am Ende des Textes).

Eine der Herausforderungen beim Risikoradar besteht darin, aus der Unmenge an Risiken und Warnmeldungen diejenigen zu finden, die für das Projekt zur echten Gefahr werden können. Dabei kann die Erfahrung des Projektleiters sowohl hilfreich als auch hinderlich sein. Der Versuch, Risiken und Probleme durch den Blickwinkel bereits gemachter Erfahrungen zu antizipieren, kann die Wahrnehmung für erstmalige Hindernisse entscheidend einschränken.

Besser und wirksamer ist, die als kleine Themen am Horizont auftauchenden Risiken systematisch zu beobachten und die wichtigsten davon in ein vertieftes Monitoring zu überführen. Parallel dazu ist sicherzustellen, dass sich ein bereits zur konkreten Gefahr entwickeltes Risiko durch geeignete Gegenmassnahmen begrenzen und damit eine Kettenreaktion verhindern lässt.

Der amerikanische Managementforscher Igor Ansoff hat in den 70er-Jahren des letzten Jahrhunderts das Konzept der sogenannten Weak Signals entwickelt. Dabei hat er aufgezeigt, dass sich einige der zuerst kaum wahrnehmbaren Risiken mit der Zeit und über fünf Entwicklungsstufen hinweg zu ernsten Gefahren entwickeln können:

Stufe 1: Ein Gefühl der bevorstehenden Störung/Bedrohung ist vorhanden;

Stufe 2: Der Ursprung der Störung/Bedrohung ist identifiziert;

Stufe 3: Die Bedrohungs-Charakteristika (Auswirkungen, Zeitablauf, Wahrscheinlichkeit) sind konkret;

Stufe 4: Mögliche Massnahme(n) sind identifiziert, geplant und budgetiert;

Stufe 5: Das Ergebnis der Massnahmen inkl. ihrer Konsequenzen ist bekannt.

Interessanterweise postuliert Ansoff auch, dass bei fehlender Vorbereitung ab Stufe 4 eine Dynamik einsetzen kann, bei der auch gezielte, aber verspätete Gegenmassnahmen wirkungslos bleiben.

Wichtig bei einem auf Projektbedürfnisse adaptierten Weak Signals-Konzept ist die Unterscheidung zwischen Screening und Monitoring. Ersteres beinhaltet die laufende Beurteilung auftauchender Gefahren auf dem Radarmonitor des Projektleiters oder der Projektleiterin:

Die einzelnen Risiken machen sich in unterschiedlicher Grösse und (zeitlicher) Distanz zum Zentrum des Geschehens bemerkbar. Beim Versuch, diejenigen Punkte/Risiken zu identifizieren, die sich über die Zeit zu handfesten Problemen entwickeln können, können einfache Fragestellungen helfen:

Eine ähnliche Methode, wie ich sie bereits in der letzten Kolumne über die initiale Risikobeurteilung vorgestellt habe, lässt sich auch für das kontinuierliche Risikomanagement verwenden (s. unten). Die beim Screening auftauchenden Gefahren werden dabei einer der folgenden Kategorien zugeordnet:

Vom Screening ins Monitoring "befördert" wird dabei nur ein Risiko, das nach dem 80/20-(Pareto-) Prinzip und im Rahmen einer 3D-Betrachtung eingeschätzt und entsprechend seiner Dringlichkeit, Wahrscheinlichkeit und Auswirkung als mindestens gelb eingestuft wurde.

Nur bei grossen IT-Projekten wird es sich lohnen, eine Risikomanagerin oder einen Risikomanager mit dem kontinuierlichen Screening und Monitoring allfälliger Gefahren zu betrauen. Dazu ist eine präzise Ausgestaltung ihrer Aufgaben, Kompetenzen und Verantwortlichkeiten notwendig.

Die Aufgabe scheint relativ klar definierbar zu sein: Screening möglicher Gefahrenherde, 80/20-(Pareto)-Identifikation der im Monitoring vertieft zu analysierenden Risiken sowie die Kommunikation der grössten Gefahren gegenüber der Projektleiterin, dem Steuerungsausschuss und den Stakeholdern.

Aber welche Verantwortung hat ein Risikomanager zu tragen, wenn er aus der Vielzahl möglicher Warnsignale die falsche Auswahl trifft und dabei eine akute, schwerwiegende Gefahr übersieht oder falsch einschätzt? Ähnlich zur Verantwortung von Wirtschaftsprüfern ist ein Risikomanager nur dafür verantwortlich, seine Arbeit nach bestem Wissen und Gewissen und den branchenüblichen Qualitätsstandards abzuliefern. Welche Schlussfolgerungen und Entscheidungen die Verantwortungsträger im Projekt- und Linienmanagement daraus ableiten, liegt dagegen nicht mehr in der Verantwortung des Risikomanagers.

Die Kompetenzen einer mit dem Risikomanagement betrauten Person müssen deckungsgleich mit ihrer Verantwortung sein. Das bedeutet, dass eine Risikomanagerin ihre Erkenntnisse jederzeit und auf der jeweils angemessenen Governance-Stufe präsentieren kann.

Wer im Team kann/soll die undankbare Rolle eines (Teilzeit-)Riskmanagers übernehmen? Idealerweise ist dies der hartnäckigste Mahner, Kritiker und als "Stein im Schuh" geächtete Bedenkenträger. Im Beispiel des Finanzinstitutes (siehe Kasten) war eines der fachlich am besten qualifizierten Teammitglieder. Seine wöchentlichen Statusübersichten allerdings strotzten nur so von roten Punkten, weil er überall Risiken und Gefahren ortete. Seien wir ehrlich: Er hat mich und andere im Team genervt. In seinen Augen stand das Projekt am Abgrund und sobald er seine Stimme erhob, war einigen Teammitgliedern das kollektive Augenverdrehen deutlich anzumerken. Alle wussten, dass maximal drei seiner gefühlt 23 roten Punkte tatsächlich ernst zu nehmen waren, aber welche?

Rückblickend gesehen, bereue ich es, ihn nicht zum Risikomanager ernannt und mit dem Konzept der Weak Signals und der damit verbundenen Verantwortung vertraut gemacht zu haben. Dies hätte ihn gezwungen, regelmässig eine 80/20-Analyse seiner Sorgen vorzunehmen und sich dabei auf diejenigen Risiken zu konzentrieren, die sich über die Zeit zu echten Gefahrenherden entwickeln konnten. Ich bin sicher, dass der disziplinierende Weak Signal-Ansatz sowohl der Zusammenarbeit im Team als auch dem Projekt selbst zum Vorteil gereicht hätten.

Wie aus zahlreichen Untersuchungsberichten gescheiterter IT-Projekte hervorgeht, bewahrt auch eine Vielzahl an Reviews, Audits und Kontrollen nicht vor dem möglichen Scheitern. Die Lösung kann deshalb nur in besserer und nicht in noch mehr Aufsicht und Kontrolle liegen.

Der Weak Signal-Ansatz scheint dafür bei Grossvorhaben ein vielversprechender Ansatz zu sein.