Rollout-Checkliste (Go-Live-Checkliste)
Aufschreiben, was vor dem Go-Live erfüllt sein muss, für jeden Punkt einen Nachweis verlangen und den Start anhalten, wenn ein kritischer Punkt scheitert.
- Zeit
- 45 Min.
- Personen
- 4–6
- Art der Arbeit
- Planen · Skalieren
Kurz gesagt
Eine Rollout-Checkliste ist eine Liste betrieblicher Bereitschaftsbedingungen, die ein neuer Service oder eine Änderung vor dem Go-Live erfüllen muss. Jede Bedingung hat eine verantwortliche Rolle, einen Termin, einen Status und vor allem einen Nachweis, dass sie erfüllt ist. Das Team legt vorab fest, welche Punkte kritisch sind, und hält den Rollout an, wenn einer davon scheitert.
Worum es geht
Die meisten Probleme beim Start sind keine Überraschungen. Jemand wusste, dass die Hotline nicht gebrieft war oder eine Zahlungsart nie ausprobiert wurde, aber es stand nirgends, wo die Entscheidenden hinsahen. Eine Rollout-Checkliste bündelt diese Bedingungen vor dem Start an einem Ort, damit die Go/No-Go-Entscheidung auf Fakten beruht statt auf Optimismus.
Mehr als eine To-do-Liste wird sie durch die Spalte Nachweis. „Erledigt“ reicht nicht. Jeder Punkt braucht einen kurzen Beleg: ein Testprotokoll, ein unterschriebenes Formular, einen Screenshot, eine Teilnehmerliste der Schulung. Außerdem markiert die Checkliste einige Punkte als kritisch. Scheitert ein kritischer Punkt, wartet der Rollout, ganz gleich, wie groß der Druck ist, den Termin zu halten.
Wann sie passt
Geeignet, wenn
- Ein neuer oder geänderter Service geht demnächst an die Öffentlichkeit oder an eine große Gruppe von Mitarbeitenden.
- Mehrere Teams müssen gleichzeitig bereit sein, damit der Start funktioniert.
- Ein früherer Start ging schief, weil etwas, das alle für fertig hielten, es nicht war.
- Die Leitung braucht eine klare, belegte Grundlage für eine Go/No-Go-Entscheidung.
Ungeeignet, wenn
- Die Arbeit wird noch entworfen oder getestet; eine so frühe Checkliste wird zur Wunschliste.
- Die Änderung ist klein und leicht rückgängig zu machen, etwa ein Text auf einer Seite; eine kurze Gegenprüfung durch Kolleginnen oder Kollegen genügt.
- Gesucht wird eine lange generische Vorlage; wer eine kopiert, ohne über den eigenen Service nachzudenken, übersieht das Wesentliche.
Was es braucht
- Zeit
- Etwa 45 Minuten für die erste Version, dann vor dem Start jede Woche ein kurzer Abgleich.
- Personen
- Vier bis sechs Personen: die Service-Verantwortlichen und je eine Leitung aus jedem Team, das bereit sein muss, etwa IT, Betrieb, Kundenservice und Kommunikation.
- Material
- Das Arbeitsblatt mit Bereitschaftsprüfung, Nachweis, Verantwortlich, Fällig und Status; die Roadmap oder der Startplan; Ergebnisse früherer Tests oder eines Pre-Mortems.
So läuft es ab
Schritt 1: Bereitschaftsbedingungen nach Bereichen sammeln
Jede Leitung bitten aufzulisten, was in ihrem Bereich vor dem Start erfüllt sein muss: Systeme, Menschen, Prozesse, Kommunikation, Support und Rückfallweg. Jede Bedingung als erreichten Zustand formulieren, etwa „Alle drei Kartentypen schließen die Zahlung im Live-System ab“.
Schritt 2: Bedingungen aus früheren Fehlschlägen ergänzen
Ansehen, was bei früheren Starts schiefging und was das Pre-Mortem ergeben hat, falls es eines gab. Für jedes ernste Risiko eine Bedingung ergänzen. Diese Punkte sind oft die wertvollsten der ganzen Liste.
Schritt 3: Kritische Punkte markieren
Vereinbaren, welche Bedingungen den Start stoppen, wenn sie scheitern: alles, was Nutzenden schaden, Geld oder Daten kosten oder den Service unbrauchbar machen könnte. Die kritische Liste kurz und klar halten. Alles andere lässt sich bei Bedarf kurz nach dem Start beheben.
Schritt 4: Den Nachweis für jeden Punkt festlegen
Für jede Bedingung aufschreiben, was als Beleg gilt: ein Testprotokoll, eine unterschriebene Freigabe, eine Teilnehmerliste der Schulung, eine Live-Testtransaktion. Ist kein Nachweis möglich, die Bedingung so lange umformulieren, bis sie überprüfbar ist.
Schritt 5: Verantwortliche Rolle und Termin festlegen
Für jeden Punkt eine verantwortliche Rolle und ein Datum benennen, bis zu dem er erfüllt sein muss, mit Puffer vor dem Start. Die verantwortliche Rolle sammelt den Nachweis und aktualisiert den Status.
Schritt 6: Den Status wöchentlich prüfen
Jede Woche kurz zusammenkommen und die Liste durchgehen. Der Status lautet: nicht begonnen, in Arbeit, mit Nachweis erfüllt oder gescheitert. Das Gespräch auf kritische Punkte und Verspätetes konzentrieren.
Schritt 7: Die Go/No-Go-Entscheidung treffen
Zu einem vereinbarten Zeitpunkt vor dem Start jeden kritischen Punkt prüfen. Sind alle mit Nachweis erfüllt, geht es los. Ist ein kritischer Punkt gescheitert, den Rollout anhalten, das Problem beheben und einen neuen Termin festlegen. Die Entscheidung und wer sie getroffen hat schriftlich festhalten.
Praxisbeispiel
Ein Kfz-Versicherer stellte die Verlängerung von Policen auf einen neuen Online-Zahlungsschritt um. Eine ähnliche Änderung zwei Jahre zuvor war am Starttag gescheitert, weil ein Kartentyp abgelehnt wurde, und viele Verlängerungen blieben unbezahlt. Das Team erstellte sechs Wochen vor dem neuen Start eine Rollout-Checkliste.
Leitungen aus IT, Betrieb, Kundencenter und Kommunikation listeten 28 Bereitschaftsbedingungen auf. Sieben wurden als kritisch markiert, darunter „Alle drei akzeptierten Kartentypen schließen eine echte Verlängerungszahlung ab“ und „Rückfall auf die alte Zahlungsseite durchgängig getestet“.
Für die Kartenbedingung war der Nachweis ein Testprotokoll einer echten Verlängerung mit jedem Kartentyp im Live-System, samt Referenzen. Zwei Kartentypen bestanden in der vierten Woche. Der dritte scheiterte an einer Einstellung beim Zahlungsdienstleister.
Beim Go/No-Go-Treffen eine Woche vor dem Start war dieser kritische Punkt immer noch als gescheitert markiert. Die Service-Verantwortliche hielt den Rollout neun Tage an, bis die Einstellung korrigiert und erneut getestet war, und die Kommunikationsleitung passte die Kundenmitteilungen an.
Der neue Start ging mit allen erfüllten kritischen Punkten live. Die Anrufe wegen Zahlungsproblemen lagen im ersten Monat deutlich unter dem Niveau nach der früheren Änderung.
Zur VeranschaulichungTipps und typische Fehler
Tipps
- Die Zahl kritischer Punkte so klein halten, dass alle sie im Kopf behalten können, oft zwischen fünf und zehn.
- Nachweise verlangen, die eine skeptische Person von außen akzeptieren würde, kein mündliches „ja, passt schon“.
- Einen getesteten Rückweg einplanen, damit sich ein gescheiterter Start schnell rückgängig machen lässt.
- Briefing der Frontmitarbeitenden und Kommunikation an die Öffentlichkeit auf die Liste setzen; sie gehören genauso zur Bereitschaft wie die Systeme.
- Die Checkliste nach dem Start aufbewahren und als Ausgangspunkt für den nächsten nutzen.
Typische Fehler
- Punkte ohne Nachweis als erledigt markieren, sodass die Liste falsche Sicherheit vermittelt.
- Jeden Punkt für kritisch erklären, womit der Start entweder nie stattfinden kann oder die Regel stillschweigend ignoriert wird.
- Die Checkliste in der Woche vor dem Start aufbauen, wenn keine Zeit mehr bleibt, das Gefundene zu beheben.
- Trotz eines gescheiterten kritischen Punkts starten, weil der Termin bereits angekündigt wurde.
Was am Ende vorliegt
Am Ende liegt eine gemeinsame Liste vor mit allem, was vor dem Start erfüllt sein muss, dem Nachweis für jeden Punkt, der verantwortlichen Rolle und einer klaren Regel für das Anhalten des Rollouts. Das gibt der Leitung eine faire Grundlage für die Go/No-Go-Entscheidung und schützt Nutzende vor vermeidbaren Ausfällen. Die Checkliste mit den Meilensteinen der Roadmap verknüpfen und die Termine aus dem Stakeholder-Kommunikationsplan aufnehmen, damit Menschen zum richtigen Zeitpunkt von der Änderung erfahren. Wurde noch nicht durchgespielt, wie der Start scheitern könnte, zuerst ein Pre-Mortem durchführen.
Häufige Fragen
Was gehört auf eine Rollout-Checkliste?
Bedingungen aus allen Bereichen, die bereit sein müssen: Systeme und Daten, Menschen und Schulung, Prozesse, Kundenservice, Kommunikation und ein getesteter Rückweg. Punkte ergänzen, die auf Fehlern früherer Starts beruhen. Jeder Punkt braucht eine verantwortliche Rolle, einen Termin und einen Nachweis.
Was ist eine Go/No-Go-Entscheidung?
Ein vereinbarter Zeitpunkt vor dem Start, an dem die entscheidende Person die kritischen Punkte der Checkliste prüft. Sind alle mit Nachweis erfüllt, findet der Start statt. Ist einer gescheitert, wird der Start angehalten, bis das Problem behoben ist. Vorab klären, wer entscheidet.
Wie unterscheidet sich eine Rollout-Checkliste von einem Projektplan?
Ein Projektplan beschreibt die zu erledigende Arbeit und ihren Zeitpunkt. Eine Rollout-Checkliste beschreibt die Bedingungen, die am Ende dieser Arbeit erfüllt sein müssen, mit Nachweis. Sie ist eine Schlussprüfung, ob der Plan geliefert hat, was der Start braucht.
Werkzeugkarte
Das Arbeitsblatt, das das Team ausfüllt, ein Kästchen pro Feld.
- Bereitschaftsprüfung
- Nachweis
- Verantwortlich
- Fällig
- Status