Kritische Anforderungen nicht abgenommen
Der Fachbereich hat zentrale Punkte nicht formal bestätigt — unabhängig davon, ob die Umsetzung technisch fertig gemeldet ist. Eine mündliche Zustimmung ist keine Abnahme.
Einführung & Go-Live
Go-Live-Readiness: wann ein Start vertretbar ist — und wann nicht.
Startreife ist eine Entscheidung, kein Zustand. Sie beruht darauf, dass die Beteiligten wissen, was offen ist und was passiert, wenn es eintritt.
ThemaEinführung und Go-Live
Lesezeitca. 5 Minuten
Für wenProgrammleitung, PMO, Fachbereich
StandJuli 2026
Kurz gefasst
„Fertig" ist die falsche Frage.
Es gibt vor keinem Start einen Zustand, in dem nichts offen ist. Die beantwortbare Frage lautet deshalb nicht „sind wir fertig?", sondern: Können wir mit dem, was offen ist, in Produktion gehen — und wissen wir, was wir tun, wenn einer dieser Punkte eintritt?
Damit wird aus einem Gefühl eine Risikoabwägung, die ein Lenkungskreis tatsächlich treffen kann. Offene Punkte werden dafür nicht versteckt, sondern bewertet. Ein bekannter Fehler mit hinterlegtem Umgang ist harmloser als ein unbekannter.
Worauf ich zuerst schaue.
Mein erster Blick geht auf den Abnahmestand der fachlichen Anforderungen — nicht auf die Fehlerliste. Der Grund ist einfach: Offene Fehler sind sichtbar und werden ohnehin diskutiert. Eine Anforderung, die technisch umgesetzt aber fachlich nicht abgenommen ist, fällt vor dem Start häufig niemandem auf und danach dem Fachbereich sofort.
Danach kommt die Frage, ob der Betrieb übernehmen kann. Das ist die Prüfung, die am häufigsten zu spät erfolgt. Wenn Überwachung, Bereitschaft und der erste Support-Weg erst in der Startwoche geklärt werden, verschiebt sich das Problem nur um wenige Tage.
Der Zeitpunkt der Prüfung ist so wichtig wie ihr Inhalt: Sie muss so früh liegen, dass ein negatives Ergebnis noch Handlungsraum lässt — üblicherweise ein bis zwei Wochen vor dem geplanten Start, mit einer kurzen Bestätigung unmittelbar davor. Eine Prüfung am Vortag ist eine Formalie, weil dann niemand mehr ehrlich absagt.
Wann ich einen Start verschiebe.
Vier Gründe. Tritt einer davon zu, empfehle ich zu verschieben — auch wenn der Termin politisch gesetzt ist.
Tests unvollständig
Abnahmetests sind nicht durchlaufen oder ihre Ergebnisse nicht dokumentiert. Ein Test ohne festgehaltenes Ergebnis ist für die Entscheidung nicht verwertbar.
Fachbereich oder Betrieb nicht bereit
Schulung fehlt, die neuen Abläufe sind unklar, oder der erste Support-Weg ist nicht besetzt. Ein technisch einwandfreier Start, den niemand bedienen kann, ist kein Start.
Kein getesteter Rückfallplan
Es gibt keinen geübten Weg zurück. Das ist der Grund, bei dem am häufigsten Widerspruch kommt — und der, den ich am wenigsten verhandele.
Die Rückfallentscheidung gehört vor den Start.
Über den Abbruch zu sprechen, während alle auf den Start hinarbeiten, wirkt destruktiv. Genau deshalb wird es ausgelassen — und genau deshalb wird später unter Zeitdruck darüber diskutiert, mit unvollständigen Informationen und in einer Runde, die dafür nicht befugt ist. Jede Stunde, die diese Diskussion dauert, macht das Zurückrollen teurer, weil in der Zwischenzeit produktive Daten entstehen.
Ein Rückfallkriterium wird deshalb vorher formuliert und möglichst mechanisch prüfbar gehalten: nicht „wenn es größere Probleme gibt", sondern zum Beispiel, wenn der Cutover die geplante Dauer um mehr als eine festgelegte Zeit überschreitet, wenn ein Fehler der höchsten Schwerestufe nicht innerhalb einer festgelegten Frist behoben ist, oder wenn ein als geschäftskritisch benannter Prozess nicht ausführbar ist.
Dazu gehört eine namentlich benannte Person, die während des Cutovers entscheidungsbefugt ist — einschließlich der Befugnis, abzubrechen. Gremien sind dafür zu langsam.
Und danach: die Einführung endet nicht am Starttag.
Die Einführung ist erst abgeschlossen, wenn der Betrieb ohne Projektunterstützung arbeitet. Dieser Zeitraum braucht eine eigene Planung: erhöhte Bereitschaft, ein definierter Weg für Fehlermeldungen, ein kurzes tägliches Bild über Auffälligkeiten — und ein festgelegtes Kriterium, wann die Stabilisierung als beendet gilt.
Ohne dieses Ende bleibt das Projekt informell zuständig, oft monatelang. Ein Satz verhindert es: Die Stabilisierung endet, wenn über einen definierten Zeitraum kein Fehler oberhalb einer definierten Schwere auftritt und der Betrieb die Übernahme schriftlich bestätigt.
Steht bei Ihnen ein Start an?
Beschreiben Sie mir Systemlandschaft, Einführungsfenster und Projektphase. Sie erhalten eine Einschätzung, ob der Termin trägt — und was dafür noch fehlt.
Projekt besprechen