Risikoregister reicht nicht: Warum Projekte Risiken nach Quelle steuern sollten

Das Risikoregister bleibt wichtig.

Es beantwortet für einzelne Risiken typischerweise Fragen wie:

Eine Risk Breakdown Structure verfolgt einen anderen Zweck.

Sie organisiert Risiken hierarchisch nach ihrer Quelle. PMI nennt klassische Oberkategorien wie technische, Management-, kommerzielle und externe Risiken. Darunter werden die jeweiligen Ursprünge weiter heruntergebrochen.

Das ermöglicht eine andere Perspektive.

Angenommen, in einem Transformationsprojekt stehen folgende Risiken im Register:

Fünf Risiken.

Doch möglicherweise haben vier davon dieselbe Ursache:

Ein externer Plattformanbieter liefert eine kritische Komponente später als geplant.

Wer jedes Risiko isoliert betrachtet, sieht fünf Probleme.

Wer die Risikoquelle betrachtet, erkennt einen strategischen Engpass.

Ein Risikoregister verführt leicht zum Zählen.

Projekt A hat 18 offene Risiken.

Projekt B hat 31.

Projekt C nur neun.

Daraus lässt sich jedoch nicht automatisch ableiten, welches Projekt stärker gefährdet ist.

Auch PMI empfiehlt bei der Risk Breakdown Structure deshalb, Risiken ihren Quellen zuzuordnen und die Exposition innerhalb dieser Bereiche zusammenzuführen. Entscheidend sei nicht lediglich die höchste Anzahl von Risiken, sondern wo sich relevante Risikoexposition konzentriert.

Das ist für Management und PMO besonders interessant.

Denn zehn kleinere Risiken aus unterschiedlichen Bereichen können beherrschbar sein.

Drei Risiken, die alle an derselben geschäftskritischen Abhängigkeit hängen, können wesentlich gefährlicher sein.

Die Managementfrage sollte deshalb nicht nur lauten:

„Wie viele rote Risiken haben wir?“

Sondern:

„Auf welchen Risikoquellen liegen unsere größten Abhängigkeiten?“

Komplexe Projekte werden selten von einem einzigen Team umgesetzt.

Interne Fachbereiche, IT, Procurement, mehrere Dienstleister, Softwareanbieter und spezialisierte Partner arbeiten parallel.

Dadurch entstehen Risiken an Schnittstellen.

Beispielsweise:

Im Risikoregister können daraus sechs unterschiedliche Einträge entstehen.

Doch vielleicht liegt die eigentliche Risikoquelle in nur einer Sache:

einer ungeklärten oder zu stark konzentrierten Abhängigkeit.

Genau diese Verbindung ist für Supplier-Steuerung entscheidend.

Denn ein Dienstleister kann in zehn verschiedenen Projektrisiken auftauchen, ohne dass auf Einzelrisikoebene sichtbar wird, wie groß die kumulierte Abhängigkeit tatsächlich ist.

Nicht jedes Unternehmen benötigt dieselbe Risk Breakdown Structure.

PMI betont ausdrücklich, dass eine RBS an den jeweiligen Projektkontext angepasst werden sollte.

Für komplexe Projekte mit externen Dienstleistern sind jedoch mindestens sieben Perspektiven sinnvoll.

Welche Risiken entstehen durch externe Anbieter?

Dazu können gehören:

Relevant ist nicht nur das einzelne Supplier-Risiko.

Relevant ist auch, wie viele kritische Projektbestandteile an demselben Anbieter hängen.

Welche Arbeitspakete oder Entscheidungen hängen von Daten ab, die nicht verfügbar, nicht ausreichend aktuell oder qualitativ problematisch sind?

In KI-Projekten gewinnt dieser Bereich zusätzlich an Bedeutung.

PMI nennt unter anderem Datenqualität, Herkunft, Bias, Datenschutz und Veränderungen der Datenbasis als eigene AI-Risikoquelle.

Aber auch ohne KI gilt:

Fehlende Daten sind häufig nicht nur ein technisches Problem.

Sie können Budgetierung, Projektfortschritt, Abnahme oder Managemententscheidungen blockieren.

Welche Projekte hängen von denselben Plattformen, Schnittstellen oder Kernsystemen ab?

Eine problematische Integration kann zunächst wie ein technisches Einzelrisiko aussehen.

Im Portfolio kann sie aber mehrere Projekte gleichzeitig betreffen.

Damit wird aus einem technischen Problem ein strukturelles Risiko.

Welche Schlüsselpersonen oder Spezialkompetenzen sind mehrfach eingeplant?

Ein einzelnes Projekt kann seine Ressourcenplanung für plausibel halten.

Erst über mehrere Projekte hinweg wird sichtbar, dass dieselbe Fachperson gleichzeitig für drei kritische Meilensteine benötigt wird.

Die Risikoquelle liegt dann nicht im einzelnen Projekt.

Sie liegt in der Portfolioabhängigkeit.

Welche Themen benötigen Entscheidungen, Freigaben oder Eskalationen?

Und wie lange können sie offen bleiben?

Eine fehlende Entscheidung kann in verschiedenen Arbeitspaketen unterschiedliche Risiken erzeugen:

Budgetüberschreitung. Verzögerung. Supplier-Stillstand. Scope-Konflikt.

Im Risikoregister sind das mehrere Einträge.

Die Quelle ist möglicherweise dieselbe:

Ein ungeklärtes Entscheidungsrecht.

Welche Risiken entstehen durch finanzielle oder vertragliche Abhängigkeiten?

Ein Projekt kann beispielsweise technisch planmäßig laufen, während gleichzeitig:

Auch hier gilt:

Der rote Meilenstein ist möglicherweise nur das Symptom.

PMI schlägt für AI-enabled Projects eine eigene RBS-Verzweigung „AI and intelligent systems risk“ vor.

Darin unterscheidet PMI sieben Quellen:

Diese Einordnung ist besonders interessant, weil sie KI nicht als unspezifisches „Technologierisiko“ behandelt.

Sie fragt konkret:

Aus welcher Eigenschaft des Systems entsteht das Risiko?

Die Risk Breakdown Structure ist keine neue Erfindung für KI.

PMI führt sie seit vielen Jahren als Methode des Projektrisikomanagements. Die Grundidee ist, Risikoursachen hierarchisch zu strukturieren, statt ausschließlich unverbundene Einzelrisiken zu betrachten.

KI macht diese Logik allerdings aktueller.

Denn sobald Systeme nicht mehr nur Informationen liefern, sondern Entscheidungen vorbereiten oder sogar eigenständig Aktionen ausführen, entstehen zusätzliche Fragen.

PMI nennt beispielsweise ein autonomes System, das innerhalb bestimmter Grenzen selbst agieren darf.

Dann reicht es nicht mehr zu fragen:

„Kann das Modell einen Fehler machen?“

Zusätzlich relevant ist:

„Was darf das System tun, wenn es falsch liegt?“

Daraus entsteht eine Verbindung zwischen Risiko, Entscheidungsrecht und Eskalation.

PMI unterscheidet für AI Agents beispielhaft unterschiedliche Grade zulässiger Autonomie.

Bei niedrigem Risiko können begrenzte, reversible Aufgaben automatisiert ausgeführt werden.

Bei höherem Risiko kann ein System lediglich Empfehlungen vorbereiten, während ein Mensch die Ausführung freigibt.

Bei besonders kritischen Bereichen – etwa mit finanziellen, rechtlichen, sicherheitsrelevanten oder personellen Auswirkungen – sollte die autonome Handlungsmöglichkeit entsprechend begrenzt sein.

Der interessante Punkt für Projektsteuerung liegt weniger in der konkreten KI-Systematik.

Er liegt im Prinzip:

Ein Risiko ist erst steuerbar, wenn eine Grenze definiert ist, ab der gehandelt werden muss.

Das gilt genauso für Budget, Termine und Supplier Performance.

Zum Beispiel:

Ein Risikoregister beschreibt das Problem.

Steuerung benötigt zusätzlich den Trigger für die Entscheidung.

Für Managementzwecke lässt sich die Risk-Breakdown-Logik deshalb weiterdenken.

Nicht nur:

Risiko → Wahrscheinlichkeit → Auswirkung

sondern:

RISIKOQUELLE → EXPOSITION → OWNER → SCHWELLE → ENTSCHEIDUNG

Wo entsteht das Risiko?

Supplier? Daten? System? Ressourcen? Vertrag? Governance?

Welche Projekte, Budgets, Termine oder Deliverables hängen daran?

Wer beobachtet und verantwortet diese Risikoquelle?

PMI betont ausdrücklich, dass jede RBS-Verzweigung einen Verantwortlichen benötigt, der sie beobachtet.

Ab welchem Punkt reicht Beobachtung nicht mehr?

Wer muss dann welche Entscheidung treffen?

Erst mit dieser letzten Ebene wird aus Risikotransparenz aktive Steuerung.

In klassischen Risikoregistern wird häufig jedem Risiko ein Risk Owner zugeordnet.

Das bleibt sinnvoll.

Aber bei strukturellen Risikoquellen kann eine zweite Verantwortlichkeit notwendig werden.

Beispiel:

Fünf Projektleiter besitzen jeweils ein Risiko, das von demselben strategischen IT-Dienstleister abhängt.

Jeder steuert sein eigenes Risiko korrekt.

Trotzdem fehlt möglicherweise jemand, der die kumulierte Supplier-Exposition über alle fünf Projekte betrachtet.

Das gleiche Problem kann bei:

auftreten.

Lokale Verantwortung ist dann vorhanden.

Übergreifende Verantwortung fehlt.

Genau deshalb ist die Risk Breakdown Structure auch für Portfolio-Steuerung interessant.

Ein einzelnes Projekt erkennt:

„Dienstleister X liefert möglicherweise zwei Wochen später.“

Das Portfolio erkennt:

„Dienstleister X ist gleichzeitig für sechs priorisierte Vorhaben kritisch.“

Das ist eine andere Managementinformation.

Denn die Handlungsoption kann sich verändern.

Auf Projektebene könnte man zwei Wochen warten.

Auf Portfolioebene könnte die Organisation feststellen, dass sie eine strategische Abhängigkeit geschaffen hat, die aktiv reduziert werden sollte.

PMI weist bereits in seiner grundlegenden RBS-Literatur darauf hin, dass ein gemeinsamer Strukturrahmen Risiken auch projektübergreifend vergleichbarer machen kann.

Die Konsequenz sollte nicht sein, neben dem Risikoregister einfach noch eine weitere umfangreiche Tabelle zu pflegen.

Dann entsteht nur eine zusätzliche Datenquelle.

Das Ziel ist vielmehr, vorhandene Risiken in einen nachvollziehbaren Zusammenhang zu bringen.

Eine RBS sollte deshalb keine zweite vollständige Risikodatenbank sein.

Sie beantwortet eine spezifische Frage:

Welche Quellen erzeugen unsere Risiken?

Die Einzelrisiken und ihre Maßnahmen bleiben im Register.

Die RBS zeigt ihre Struktur.

Genau diese Trennung macht sie managementrelevant.

Aus Ramp7-Perspektive ist ein Risiko erst dann wirklich steuerungsrelevant, wenn sein Kontext sichtbar wird.

Ein Supplier-Risiko ohne betroffene Projekte ist unvollständig.

Ein Terminrisiko ohne Kostenwirkung ist unvollständig.

Eine Budgetabweichung ohne Ursache ist unvollständig.

Ein roter Status ohne Verantwortlichen und Entscheidungszeitpunkt ist unvollständig.

Die relevante Verbindung lautet deshalb:

RISIKOQUELLE → PROJEKT → SUPPLIER → KOSTEN/TIMING/QUALITÄT → VERANTWORTUNG → ENTSCHEIDUNG

Project Intelligence bedeutet in diesem Kontext nicht, möglichst viele Risiken zu erfassen.

Es bedeutet, Informationen so zusammenzuführen, dass Management erkennt, wo sich Abhängigkeiten und Risikoexposition tatsächlich konzentrieren.

Ramp7 positioniert Project Intelligence grundsätzlich als Steuerungsperspektive auf externe Leistungen, Projekte, Budgets, Risiken und Managemententscheidungen.

Daraus wird für diesen Artikel ausdrücklich nicht abgeleitet, dass Ramp7 heute Risiken automatisch erkennt, AI-Risiken klassifiziert, Predictive Alerts erzeugt oder autonome Systeme kontrolliert. Solche konkreten Produktclaims sind für diesen Entwurf nicht erforderlich.

Projektleiter, PMO und Management können ihr heutiges Risikomanagement mit acht Fragen testen:

Mehrere Nein-Antworten bedeuten nicht, dass das Risikoregister schlecht geführt wird.

Sie zeigen etwas anderes:

Die einzelnen Risiken sind sichtbar – ihre gemeinsame Struktur möglicherweise noch nicht.

Ein gutes Risikoregister beantwortet:

Was könnte schiefgehen?

Eine Risk Breakdown Structure ergänzt:

Woher kommt dieses Risiko?

Und moderne Projektsteuerung sollte noch zwei weitere Fragen anschließen:

Welche anderen Projekte und Supplier hängen an derselben Quelle?

Wann muss daraus eine Entscheidung entstehen?

Gerade in komplexen Multi-Supplier- und KI-Projekten liegt darin ein wesentlicher Unterschied.

30 sauber dokumentierte Risiken können weniger aussagekräftig sein als die Erkenntnis, dass zwölf davon auf dieselbe kritische Abhängigkeit zurückgehen.

Die entscheidende Managementfrage lautet deshalb nicht nur:

„Welche Risiken stehen in unserem Register?“

Sondern:

„Wo konzentriert sich unsere tatsächliche Risikoexposition – und können wir handeln, bevor daraus mehrere Probleme gleichzeitig werden?“