Risiken als Tickets: Wie wir Go-Live-Risiken in Enterprise-Projekten steuerbar machen
Jedes ordentliche Angebot hat einen Risiken-Abschnitt. "Abhängigkeit von Drittsystemen", "Datenqualität der Altbestände", "Verfügbarkeit fachlicher Ansprechpartner". Der Abschnitt wird gelesen, abgenickt – und dann passiert das, was mit Risiken in Projekten meistens passiert: Sie verschwinden im Angebotsdokument, während das Projekt in Tickets, Boards und Sprints weiterläuft.
Bis sie kurz vor Go-Live wieder auftauchen. Dann als Problem, nicht als Risiko. Ohne Vorlauf, ohne Entscheidungsgrundlage, dafür mit hohem Puls.
Wir machen das anders: Risiken werden bei uns Vorgänge. Sie liegen im selben Board wie die Umsetzung, haben eine Nummer, einen Verantwortlichen und ein Datum, bis zu dem entschieden sein muss. Das klingt nach Formalismus. Es ist das Gegenteil – es ist der Weg, wie Risiken aus der Grauzone in die Realität kommen.
Das Format: R-Nummer, Auswirkung, Owner, Entscheidungsdatum
Ein Risiko-Vorgang besteht bei uns aus fünf Feldern. Mehr braucht es nicht, weniger funktioniert nicht.
R-Nummer. Eine eindeutige Kennung (R-01, R-02, …). Klingt banal, ist der wichtigste Teil: Ein Risiko mit Nummer ist zitierbar. Im Status-Report, im Meeting, in der E-Mail an den Auftraggeber. "Wir hängen an R-04" ist eine präzise Aussage – "die Sache mit der Schnittstelle" ist keine.
Beschreibung. Was genau ist die Annahme oder Unsicherheit? Nicht "API-Risiko", sondern: "Wir gehen davon aus, dass die Fremd-API die Felder X und Y in allen Sprachen liefert. Bestätigt ist das nicht."
Auswirkung. Was passiert, wenn es eintritt – in Projektbegriffen, nicht in Adjektiven. Nicht "kritisch", sondern: "Feature Z kann nicht wie spezifiziert gebaut werden, Alternative kostet ca. X Tage, betrifft den Go-Live-Termin."
Owner. Eine Person, kein Team. Und häufig sitzt der Owner auf Kundenseite – denn viele Risiken kann nur der Auftraggeber auflösen: Wer entscheidet, ob Feature Z im Scope bleibt? Wer beschafft die Daten? Diese Zuordnung offen ins Ticket zu schreiben, ist der unbequeme, aber entscheidende Schritt.
Entscheidungsdatum. Bis wann muss eine Entscheidung fallen, damit sie noch etwas kostet, das man bezahlen will? Dieses Datum ergibt sich aus der Umsetzungsplanung – und macht sichtbar, dass Nichtentscheiden auch eine Entscheidung ist, nur eine teurere.
Der Kniff liegt im Ort: im selben Board wie die Umsetzung. Kein separates Risiko-Excel, das niemand öffnet. Ein Risiko-Ticket kann Umsetzungstickets blockieren – und dann ist im Board sichtbar, dass ein Arbeitspaket nicht auf Code wartet, sondern auf eine Entscheidung.
Drei Risikoklassen, die es fast immer gibt
Aus unseren Enterprise-Projekten (anonymisiert) wiederholen sich drei Muster:
Die Annahme "stabile Fremd-API". Fast jedes Integrationsprojekt hängt an Systemen, die jemand anderes betreibt: PIM, ERP, CRM, Zahlungsdienstleister. Die Dokumentation verspricht etwas, die Realität liefert etwas anderes – fehlende Felder, unerwartete Nullwerte, Änderungen ohne Ankündigung. Als Risiko-Ticket formuliert: Welche konkreten Annahmen treffen wir, wer bestätigt sie, und was ist der Plan B? Wir haben gelernt, solche Annahmen früh gegen echte API-Responses zu prüfen statt gegen Dokumentation – das verwandelt Risiken in Fakten, solange sie noch billig sind.
Scope-Entscheidungen vor Go-Live. In jedem Projekt kommt der Punkt, an dem klar wird: Nicht alles wird zum Termin fertig. Die Frage ist nicht ob dieser Punkt kommt, sondern ob er vier Wochen vorher besprochen wird oder vier Tage. Als Risiko mit Entscheidungsdatum angelegt, wird daraus ein geplanter Termin statt einer Krisensitzung – mit Optionen statt Notlösungen.
Datenverfügbarkeit vs. Code-Freeze. Der Klassiker bei datengetriebenen Projekten: Die Anwendung ist fertig, aber die Inhalte oder Migrationsdaten sind es nicht. Beide Seiten warten aufeinander, niemand hat es aufgeschrieben. Als Ticket mit Owner auf Kundenseite und hartem Datum wird die Abhängigkeit zu einer Aufgabe mit Termin.
Status-Report mit Ampel je Arbeitspaket
Risiko-Tickets allein reichen nicht – es braucht einen Rhythmus, in dem sie sichtbar werden. Dafür nutzen wir einen kurzen Status-Report je Arbeitspaket, mit Ampel:
- ON TRACK – läuft nach Plan, kein Eingriff nötig
- CAUTION – es gibt ein offenes Risiko oder eine ausstehende Entscheidung, die den Plan gefährdet
- BLOCKED – Stillstand, mit Verweis auf die R-Nummer
Wichtig ist die Disziplin bei CAUTION. Der Status ist wertlos, wenn er erst gesetzt wird, wenn schon alles brennt – und genauso wertlos, wenn dauerhaft alles gelb ist. CAUTION heißt: Es gibt etwas zu entscheiden, und zwar jetzt.
Dazu gehört ein Follow-up-Dokument statt Meeting-Gedächtnis. Nach jedem Status-Termin werden Entscheidungen, offene Punkte und neue Risiken schriftlich festgehalten – nicht als Protokoll zum Abheften, sondern als Arbeitsdokument, das im nächsten Termin die Grundlage bildet. Wer sich auf mündliche Absprachen verlässt, diskutiert dieselbe Frage dreimal und erinnert sich an drei verschiedene Ergebnisse.
Was das bringt
Risiken werden entschieden statt vererbt. Das ist der Kern. Ein Risiko ohne Owner und Datum wandert von Sprint zu Sprint, bis es Realität wird. Mit beidem wird es zu einem Vorgang, der irgendwann geschlossen ist – durch eine Entscheidung, eine Absicherung oder die Erkenntnis, dass es keins mehr ist.
Eskalation wird unpolitisch. Das ist der unterschätzte Effekt. Wenn ein Risiko dokumentiert ist, mit Owner und Datum, ist das Ansprechen keine Schuldzuweisung mehr, sondern Prozess. "R-04 ist überfällig, wir brauchen bis Freitag eine Entscheidung" ist eine sachliche Aussage. Ohne dieses Register klingt derselbe Satz nach Vorwurf – und wird entsprechend defensiv aufgenommen. Wir haben erlebt, wie sehr das die Zusammenarbeit entspannt: Es gibt keine unangenehmen Gespräche mehr, es gibt fällige Tickets.
Transparenz, die in beide Richtungen wirkt. Auch unsere eigenen Risiken stehen im Register – Punkte, die wir nicht abschließend einschätzen können. Das ist unbequem und schafft genau deshalb Vertrauen: Ein Dienstleister, der nur die Risiken des Kunden dokumentiert, führt keine Liste, sondern baut eine Verteidigungslinie.
Grenzen: Ab wann lohnt sich der Overhead?
Ehrlich bleiben: Für ein zweiwöchiges Feature-Paket ist ein Risikoregister Unsinn. Der Overhead lohnt sich, wenn mindestens eins davon zutrifft:
- Mehrere Beteiligte über Organisationsgrenzen – Kunde, Dienstleister, weitere Zulieferer
- Harte Termine, an denen etwas hängt (Kampagne, Messe, Vertragsfrist, Abschaltung eines Altsystems)
- Abhängigkeiten von Systemen oder Daten, die nicht im eigenen Zugriff liegen
- Laufzeit über mehrere Monate, in denen Beteiligte und Prioritäten wechseln
Trifft nichts davon zu, reicht eine kurze Annahmen-Liste im Ticket. Und ein Register, das nicht gepflegt wird, ist schlechter als keins – es erzeugt das Gefühl von Kontrolle, ohne sie zu liefern. Ein Register lebt von zwei Dingen: Es wird in jedem Status-Termin durchgegangen, und veraltete Einträge werden geschlossen statt mitgeschleppt.
Fazit
Risiken im Angebot sind Prosa. Risiken als Vorgänge – mit Nummer, Auswirkung, Owner und Entscheidungsdatum, im Board neben der Umsetzung – sind Steuerung. Der Unterschied zeigt sich nicht in ruhigen Projektphasen, sondern in den vier Wochen vor Go-Live: Dort entscheidet sich, ob Überraschungen Krisen sind oder terminierte Entscheidungen.
Startet gerade ein Projekt mit harten Terminen und vielen Abhängigkeiten? Im Projekt-Setup-Gespräch schauen wir uns euer Vorhaben an und zeigen, wie wir Risiken, Status-Reporting und Entscheidungswege aufsetzen würden – unabhängig davon, ob wir die Umsetzung machen.
Fachlich geprüft von Johannes
Johannes hat an diesem Projekt selbst mitgearbeitet und diesen Artikel auf technische & fachliche Richtigkeit geprüft. KI-gestützt geschrieben, von Menschen verantwortet.
Zum Profil von Johannes