Bestandsmigration mit hartem Termin: rote Ampel, Nachträge und ausscheidende Schlüsselperson
Bei der Nordlicht Versicherung AG läuft das Projekt „Bestandsmigration Polizzen“ seit elf Monaten. Von sieben Meilensteinen sind zwei erreicht; der Meilenstein „Migrationsstrecke produktionsreif“ hat 14 Wochen Verzug. Der feste Termin ergibt sich aus der Abkündigung des Altsystems durch den Hersteller zum 31.03. – danach fallen Support und Lizenzen weg; eine Verlängerung der Restlaufzeit kostet 480.000 Euro. Der externe Dienstleister rechnet nach Aufwand; Nachträge von 340.000 Euro liegen vor. Der fachliche Product Owner ist zu 20 Prozent abgestellt und entscheidet nicht; Anforderungen ändern sich im Wochentakt. Die Kernentwicklerin (Migrationslogik, neun Jahre Altsystem-Kenntnis) hat gekündigt, Austritt in sechs Wochen. Die Testabdeckung liegt bei 38 Prozent der 1.200 Fachfälle automatisiert. Das Steuerungsgremium tagt in zehn Tagen und erwartet eine Statusampel mit Empfehlung.
1. Formulieren Sie für das Steuerungsgremium eine Empfehlung: Ampellogik, drei Optionen mit Konsequenzen in Zeit, Kosten und Risiko sowie eine klare Empfehlung.
Read the worked answer
Ampel: Rot. Begründung in drei Sätzen: Termin gefährdet, Kosten unkontrolliert, Wissensträgerin scheidet aus. Eine grüne Ampel wäre keine Optimierung, sondern ein Glaubwürdigkeitsverlust – und in zehn Tagen offensichtlich falsch.
Optionen:
- A – Termin halten durch Scope-Reduktion: Migration der Standardpolizzen (ca. 70 Prozent) bis 31.03., Restbestand über einen definierten Sonderprozess bis 30.09. Kosten: geringer Nachtrag, dafür höhere manuelle Kosten im Übergang. Risiko: mittel und beherrschbar, weil der Kernprozess läuft.
- B – Termin verschieben: Restlaufzeit-Verlängerung 480.000 Euro plus Opportunitätskosten, dafür voller Scope. Risiko: politisch hoch, und die Verlängerung ist nicht zugesagt – sie ist eine Annahme, keine Option.
- C – Parallelbetrieb/Altsystem einfrieren: technisch meist nicht tragfähig, weil der Support entfällt; taugt als Notfallplan, nicht als Strategie.
Empfehlung: A mit Elementen von B – Scope auf Standardpolizzen reduzieren, Restbestand mit verbindlichem Nachzugstermin, Verlängerung nur für die Reststrecke einkaufen und den Preis gegen die 340.000 Euro Nachtrag stellen. Zusätzlich Änderungsstopp für den Kernscope; ohne ihn ist jede Variante in vier Wochen wieder überholt.
Was das Gremium entscheiden muss: Scope-Schnitt, Änderungsstopp, Budget für die Reststrecke. Nicht die technische Lösung – diese Entscheidungen gehören nicht in ein Steuerungsgremium.
2. Wie sichern Sie das Wissen der in sechs Wochen ausscheidenden Kernentwicklerin? Beschreiben Sie Vorgehen, Priorisierung und Abbruchkriterien.
Read the worked answer
1. Risikokarte zuerst (zwei Tage). Welche Migrationsregeln kann nur sie erklären? Priorisierung nach Schaden bei falscher Migration und nach Häufigkeit (Anzahl betroffener Polizzen), nicht nach Vollständigkeit. Realistische Erwartung: 20 bis 30 kritische Regeln, nicht 500.
2. Transfer an Personen, nicht an Dokumente. Zwei Entwickler übernehmen je eine Hälfte als Paten. Format: gemeinsame Sessions am laufenden Code – sie erklärt, der Pate schreibt mit und stellt Rückfragen. Wer nur zuhört, hat nichts gelernt; wer nur Dokumente erhält, auch nicht.
3. Rückgabe als Nachweis. Jeder Pate führt eine Migration selbstständig durch und erklärt die Regel im Review. Erst dann gilt sie als übergeben. Ohne dieses Kriterium ist die Übergabe eine Illusion mit Protokoll.
4. Artefakte mit Ziel. Jede kritische Regel wird als Testfall im Testpaket abgelegt – eine Regel ohne Testfall ist mit dem Austritt verloren. Dazu kurze Entscheidungsnotizen zu Sonderfällen.
5. Vertraglich absichern. Prüfen, ob eine befristete Beratertätigkeit nach Austritt möglich ist (Genehmigung, Vergütung, Zeitfenster) – als Netz für die zwei oder drei Regeln, die niemand versteht. Nicht als Ersatz für den Transfer.
6. Zeit realistisch schneiden. Sechs Wochen minus Urlaub und Abschiedstermine sind etwa 15 Arbeitstage. Das reicht für Risikokarte und 20 Regeln, nicht für Vollständigkeit. Deshalb die Priorisierung nach Schaden – und deshalb gehört diese Rechnung in die Statusmeldung an das Gremium.
3. Was ändern Sie am Vorgehen und an der Governance, damit die verbleibenden Wochen nicht im gleichen Muster weiterlaufen?
Read the worked answer
Diagnose: Das Projekt hat kein Lieferproblem, sondern ein Entscheidungsproblem. 20 Prozent Product Owner, wöchentlich wechselnde Anforderungen und ein Dienstleister nach Aufwand erzeugen gemeinsam den Verzug – jeder Faktor allein wäre beherrschbar.
Maßnahmen, nach Ursachennähe sortiert:
- Entscheidungsrecht klären. Product Owner auf mindestens 60 Prozent abstellen oder eine entscheidungsbefugte Vertretung benennen. Ohne diese Personalentscheidung sind alle Prozessmaßnahmen folgenlos.
- Änderungsstopp mit engem Tor. Änderungen nur noch über ein wöchentliches Change Board mit Aufwandsschätzung und Tauschgeschäft: neue Anforderung rein, gleich große raus. Alles andere ist eine Wunschliste mit Projektlogo.
- Definition of Ready erzwingen. Keine Anforderung ohne Akzeptanzkriterium und Testfall geht in die Entwicklung; das hebt zugleich die Testabdeckung von 38 Prozent.
- Dienstleister auf Festpreis je Migrationswelle umstellen. Nachträge nur gegen Scope-Verzicht. Sonst bleibt das finanzielle Risiko vollständig beim Auftraggeber.
- Steuerung auf Ergebnisgrößen. Wöchentlich: migrierte Polizzen, automatisierte Testfälle, offene Entscheidungen mit Alter in Tagen. Keine Fortschrittsprozente.
- Wissensrisiko in die Statusmeldung. Der Austritt der Kernentwicklerin gehört mit Termin und Maßnahme in das Gremium, nicht in eine Randnotiz.
Reihenfolge: 1 und 2 vor 3 bis 5, weil sie die Ursache adressieren. Ein neues Dashboard auf unveränderten Entscheidungswegen erzeugt nur bessere Bilder desselben Problems – und das Gremium tagt in zehn Tagen, nicht in zehn Wochen.