Ein Risk-Log braucht allzu oft zu viele Zeilen, bis irgendjemand im Raum wirklich versteht, was mit was zusammenhängt. Bei uns im Team lag die Antwort lange bei einer Excel-Tabelle mit über zweihundert Einträgen, säuberlich sortiert nach Wahrscheinlichkeit und Schadensausmaß, vollständig, aber nie hilfreich, wenn es wirklich brannte. Genau da liegt der Denkfehler, den ich im Risikomanagement für SaaS-Projekte am häufigsten sehe: Vollständigkeit wird mit Kontrolle verwechselt. Visuelles Denken im Team, sprich Sketchnotes statt Tabellenzeilen, macht diesen Unterschied sichtbar, nicht weil hübschere Bilder mehr Sicherheit geben, sondern weil sie Zusammenhänge zeigen, die eine Liste strukturell verstecken muss.
Nehmen wir eine Standard SaaS Uptime SLA von 99,9 Prozent, in einer Tabelle liest sich das wie eine harmlose Kennzahl. In Wirklichkeit reißt eine hängende API eines Drittanbieters, und das komplette Dashboard steht still. Im Risk-Log ist das Zeile 42 und Zeile 118, zwei getrennte Einträge. In echt ist es eine einzige Kettenreaktion, die niemand in der Tabelle sieht, weil Tabellen keine Pfeile zwischen Zeilen zeichnen.
Der Mythos im Risikomanagement: Ein vollständiges Risk-Log schützt vor Überraschungen
Klassisches Risikomanagement arbeitet gern mit der Risikomatrix, dem 5x5-Raster aus Eintrittswahrscheinlichkeit und Schadensausmaß. Handwerklich ist daran nichts falsch. Das Problem ist, wie das Raster im Kopf wirkt: Sobald ein Risiko einen Punktwert hat, fühlt es sich bearbeitet an – auch wenn sich niemand gefragt hat, was passiert, wenn zwei gelbe Felder gleichzeitig eintreten. Genau diese Lücke schließt kein zusätzliches Feld in der Tabelle, sondern nur der Blick auf die Verbindung zwischen den Feldern.
Hauke, unser Scrum Master, erklärt seine Prozesse ohnehin nie nur in Worten, sondern zieht am liebsten den Marker und skizziert sie live aufs Whiteboard. Genau diesen Reflex habe ich mir fürs Risikomanagement abgeschaut. Statt einer neuen Spalte zeichne ich ein Symbol: eine Gewitterwolke für eine externe API-Abhängigkeit, ein Blitz für den Auth-Service, wenn er kippt. Ein eigenes kleines Vokabular an Icons hilft dabei enorm, weil das Team die Symbole inzwischen zuverlässig wiedererkennt, ohne dass jemand eine Legende erklären muss. Unter der Neonröhre im Großraumbüro wirken die Posca-Punkte auf dem Whiteboard fast matt, nie glänzend wie frische Tinte, ein kleines Detail, aber es macht die Symbole lesbarer als das Chaos, das sie eigentlich darstellen sollen.
Visuelles Denken macht Abhängigkeiten im Team sichtbar
Anstatt Zeilen zu füllen, ordne ich Risiken inzwischen wie eine kleine Landschaft auf dem Blatt an – Kreis, Quadrat, Dreieck, Linie und Punkt reichen als Grundformen völlig aus. Wichtiger als die Form ist die Position: Ich platziere ein Symbol nah am Kernprodukt, wenn ein Ausfall dort mehrere Services gleichzeitig mitreißt, egal wie 'unwahrscheinlich' die Matrix es einstufen würde. Diese räumliche Nähe zwischen Symbolen zeigt eine Verkettung, die eine Tabelle strukturell gar nicht abbilden kann, und genau darin liegt der Unterschied zwischen einer Liste und einer Landkarte. Wer eine Datenbank-Migration oder eine Service-Abhängigkeit erklären muss, merkt schnell, wie hilfreich es ist, Software Architektur visuell darzustellen, ohne dafür ein Design-Studium zu brauchen.
Vorher hatte ich Meeting-Notizen ganz anders organisiert: eine Notion-Datenbank mit Tags, Filtern und einer sauberen Struktur, aufgesetzt an einem Nachmittag und nach einer Woche nie wieder geöffnet, weil außer mir niemand wusste, wo welche Information lag. Ein Kollege dagegen hat neulich einfach ein Foto seiner Retro-Sketchnote in unseren Team-Channel gepostet, ganz ohne zu fragen, ob das jemanden interessiert – und innerhalb von Minuten kommentierten drei Leute, welche Pfeile sie noch ergänzen würden. Kein Tool-Setup, keine Einführung, einfach ein Bild, das sofort verständlich war.
Zuhause in der Altbauwohnung in Eimsbüttel sieht mein Schreibtisch inzwischen entsprechend aus: unbehandeltes Kiefernholz, links der zweite Monitor, rechts neben der Maus liegt griffbereit ein A5-Heft. Im Regal darüber stapeln sich drei angefangene Notizbücher und lose Fineliner-Packungen, durchs Fenster zum Innenhof kommt nur diffuses Licht, nie direkte Sonne. Dort übertrage ich abends die Whiteboard-Skizzen ins Heft, weil ein Handyfoto vom Whiteboard nach zwei Tagen niemand mehr findet.
Was zeigt eine Risiko-Landkarte, das eine Prioritätsliste nicht zeigt?
Der zweite Mythos hängt eng mit dem ersten zusammen: die Annahme, Priorisierung nach Wahrscheinlichkeit führe automatisch zu den richtigen Entscheidungen. In einem SaaS-Ökosystem blockiert dieser Fokus oft die eigentliche Lösung, weil er einzelne Risiken isoliert bewertet, obwohl sie sich gegenseitig verstärken. Farbe kann diese Verstärkung sichtbar machen, wenn man sie konsequent für Dringlichkeit statt für Kategorien nutzt – das ist allerdings ein eigenes Thema für sich. Wichtiger ist die Linie zwischen zwei Symbolen: Ein Pfeil, der zwei Risiken verbindet, zeigt einen Ablauf, den keine Rangliste abbilden kann.
Rainer, ein Stammleser aus einer Sketchnotes-Facebook-Gruppe, hat mich kürzlich gefragt, ob sich solche Risiko-Landkarten auch digital pflegen lassen – er probiert gerade parallel Papier und iPad aus, was ein eigenes Fass aufmacht, das hier nicht reinpasst. Für mich zählt in dem Moment ohnehin nur, ob die Skizze im Workshop mit Stakeholdern sofort funktioniert, wenn ich sie live vor der Gruppe zeichne, statt sie vorzubereiten. Genau das unterscheidet eine Risiko-Landkarte von einem fertigen Foliensatz: Sie entsteht vor den Augen der Leute, die nachher auch dafür verantwortlich sind.
Verbindungen zeichnen statt Risiken einzeln bewerten
Man muss dafür kein Zeichner sein. Es geht um Klarheit, nicht um Ästhetik, und wer unsicher ist, kann mit ein paar einfachen Übungen anfangen, um die Lesbarkeit der eigenen Notizen zu verbessern, bevor der eigene Kringel am Ende des Meetings unlesbar wird. Bei uns gehört die Risiko-Landkarte inzwischen so selbstverständlich zum PM-Alltag dazu, dass ich verstehe, warum Vorteile von Sketchnotes im Business den PM Alltag im SaaS erleichtern, gerade wenn die Komplexität überhandnimmt.
Mein Risk-Log liegt trotzdem noch im Meeting-Ordner, für die Compliance-Seite bleibt es Pflicht. Aber bevor ich eine neue Zeile darin anlege, zeichne ich zuerst die Verbindung zum nächsten Symbol: Was reißt dieses Risiko mit, wenn es eintritt? Erst wenn diese Linie auf dem Blatt steht, trage ich den Eintrag in die Tabelle ein, nicht umgekehrt. Diese Reihenfolge ist die eigentliche Korrektur an der klassischen Methode – nicht das hübschere Bild.