Ich habe in 25 Jahren hunderte von Programmen gesteuert oder begleitet. Erfolgreiche und gescheiterte. Große und kleine. In verschiedenen Branchen, verschiedenen Größenordnungen, verschiedenen Kontexten.
Und ich habe ein Muster erkannt, das sich in fast allen wiederholt:
Programme scheitern nicht am Go-live. Sie scheitern nicht am Budget. Sie scheitern nicht an der Technologie.
Sie scheitern zwischen Tag 30 und Tag 130.
In dieser Phase — den kritischen 100 Tagen — wird entschieden, ob ein Programm erfolgreich wird oder nicht. Aber niemand achtet darauf. Weil alle auf den Go-live starren.
Wenn Sie verstehen, was in diesen 100 Tagen passiert — und wie Sie die Warnsignale erkennen — können Sie eingreifen, bevor es zu spät ist.
Warum gerade diese 100 Tage?
Die ersten 30 Tage eines Programms sind die Honeymoon-Phase. Alle sind motiviert. Der Kick-off war erfolgreich. Die ersten Workshops laufen. Die Stakeholder sind an Bord.
In dieser Phase sieht man die Probleme noch nicht. Sie sind da — aber sie sind unsichtbar.
Ab Tag 30 beginnen sie sichtbar zu werden. Aber subtil. Kleine Verzögerungen. Unklare Entscheidungen. Konflikte, die unter der Oberfläche brodeln.
Zwischen Tag 30 und Tag 130 eskalieren diese Probleme. Und in dieser Phase entscheidet sich: Wird das Programm sie lösen — oder werden sie das Programm töten?
Die kritischen 100 Tage sind nicht die spektakulärste Phase. Aber sie sind die entscheidende.
Die drei Wendepunkte
In 25 Jahren habe ich drei Muster identifiziert — drei kritische Momente, die in diesen 100 Tagen fast immer auftauchen. Jeder davon kann ein Programm kippen.
Wendepunkt 1: Der Stakeholder-Bruch (Tag 40–60)
Etwa sechs bis acht Wochen nach Programmstart passiert etwas Vorhersehbares:
Ein wichtiger Stakeholder, der beim Kick-off zugestimmt hat, äußert plötzlich Zweifel.
Nicht laut. Nicht offiziell. Aber in bilateralen Gesprächen. In E-Mails. In Nebenbemerkungen.
»Ich bin mir nicht sicher, ob wir das wirklich brauchen.«
»Die Priorisierung ist falsch.«
»Mein Team hat gerade keine Kapazitäten.«
Das ist der Stakeholder-Bruch. Und er ist tödlich — wenn man ihn nicht sofort adressiert.
Warum passiert das?
Weil in den ersten Wochen alle abstrakt zugestimmt haben. Das Programm klang gut. Die Präsentation war überzeugend. Der Business Case war klar.
Aber jetzt wird es konkret. Ressourcen müssen bereitgestellt werden. Entscheidungen müssen getroffen werden. Prioritäten müssen verschoben werden.
Und plötzlich wird klar: Das kostet etwas. Und nicht jeder ist bereit, diesen Preis zu zahlen.
Das Warnsignal: Ein Stakeholder, der vorher zugestimmt hat, beginnt zu zögern — ohne das offen auszusprechen.
Was tun?
Ich gehe direkt hin. Nicht per E-Mail. Nicht im Meeting. Sondern bilateral. Und ich stelle drei Fragen:
1. »Was hat sich geändert?«
2. »Was müsste anders sein, damit Sie das mittragen können?«
3. »Wenn wir das nicht lösen — was passiert dann?«
In 80 Prozent der Fälle ist das Problem lösbar. Der Stakeholder hat eine konkrete Sorge, die man adressieren kann.
In 20 Prozent der Fälle ist das Problem fundamental. Dann muss man eskalieren — sofort.
Aber egal was: Man muss es tun. Denn ein Stakeholder, der innerlich ausgestiegen ist, wird das Programm sabotieren — ob bewusst oder unbewusst.
Wendepunkt 2: Die Ressourcen-Krise (Tag 60–90)
Etwa zehn bis zwölf Wochen nach Programmstart kommt die Ressourcen-Krise.
Nicht weil die Ressourcen nicht da wären. Sondern weil sie nicht verfügbar gemacht werden.
Das sieht so aus:
Ein Fachbereich hat zugesagt, drei Mitarbeiter für das Programm freizustellen. Aber jetzt, wo sie gebraucht werden, sind sie in anderen Projekten eingeplant. Oder sie sind krank. Oder sie haben »keine Zeit«.
Die Linie priorisiert das Tagesgeschäft über das Programm. Und das Programm kommt ins Stocken.
Das ist nicht böswillig. Es ist rational. Die Linie wird an ihren operativen KPIs gemessen, nicht am Programmerfolg. Also priorisiert sie das, was sie messen kann.
Das Warnsignal: Ressourcen sind formal zugesagt, aber faktisch nicht verfügbar.
Was tun?
Ich eskaliere. Nicht als Drohung, sondern als Sachstandsmeldung.
Ich gehe zur Führung und sage: »Wir haben ein strukturelles Problem. Die Linie priorisiert das Tagesgeschäft über das Programm. Das ist rational — aber es tötet das Programm. Wir brauchen eine Entscheidung: Entweder wir ändern die Priorisierung, oder wir ändern den Programmplan.«
Das zwingt die Führung, eine klare Entscheidung zu treffen. Entweder sie setzt die Ressourcen frei — oder sie akzeptiert, dass das Programm langsamer läuft.
Beide Optionen sind okay. Aber Unklarheit ist tödlich.
Wendepunkt 3: Die Governance-Blockade (Tag 90–130)
Der dritte Wendepunkt kommt später — etwa drei bis vier Monate nach Programmstart.
Zu diesem Zeitpunkt ist das Programm schon weit fortgeschritten. Die ersten Deliverables sind fertig. Die Architektur steht. Der Rollout-Plan ist definiert.
Und dann kommt eine Entscheidung, die nicht getroffen werden kann.
Nicht weil die Optionen unklar wären. Sondern weil die Governance nicht funktioniert.
Das sieht so aus:
Eine strategische Weichenstellung muss getroffen werden. Zwei Geschäftsbereiche haben unterschiedliche Meinungen. Das Steuergremium tagt. Aber es kann sich nicht einigen.
Die Entscheidung wird vertagt. Auf das nächste Meeting. Dann auf das übernächste. Dann auf »sobald wir mehr Informationen haben«.
Währenddessen steht das Programm still.
Das Warnsignal: Eine Entscheidung wird mehrfach vertagt — ohne klares Kriterium, wann sie getroffen wird.
Was tun?
Ich erzwinge eine Entscheidung. Nicht durch Druck, sondern durch Struktur.
Ich gehe zum Lenkungskreis und sage: »Wir haben jetzt drei Mal über diese Frage gesprochen. Es gibt zwei Optionen. Beide haben Vor- und Nachteile. Ich brauche eine Entscheidung — heute. Wenn wir keine treffen, entscheide ich das operativ — und ich dokumentiere, dass die Entscheidung mangels Steuerung auf der Arbeitsebene getroffen wurde.«
Das funktioniert. Weil niemand will, dass eine strategische Entscheidung auf der Arbeitsebene getroffen wird.
Aber es braucht jemanden, der diese Klarheit einfordert.
Warum diese Wendepunkte so gefährlich sind
Jeder dieser drei Wendepunkte ist für sich lösbar. Aber sie sind gefährlich, weil sie schleichend eskalieren.
Ein Stakeholder, der innerlich ausgestiegen ist, sagt das nicht laut. Er zögert nur. Subtil.
Eine Ressourcen-Krise entsteht nicht über Nacht. Sie baut sich über Wochen auf.
Eine Governance-Blockade ist nicht spektakulär. Sie ist nur eine Vertagung. Dann noch eine. Dann noch eine.
Und plötzlich sind vier Monate vergangen — und das Programm ist faktisch gescheitert, obwohl es offiziell noch läuft.
Die kritischen 100 Tage sind gefährlich, weil die Probleme unsichtbar beginnen — und erst sichtbar werden, wenn es fast zu spät ist.
Wie man die Warnsignale erkennt
Wenn Sie ein Programm steuern — oder dafür verantwortlich sind — dann achten Sie auf diese drei Signale:
1. Ein Stakeholder, der vorher zugestimmt hat, beginnt zu zögern — ohne das offen auszusprechen. (Tag 40–60)
2. Ressourcen sind formal zugesagt, aber faktisch nicht verfügbar. (Tag 60–90)
3. Eine Entscheidung wird mehrfach vertagt — ohne klares Kriterium, wann sie getroffen wird. (Tag 90–130)
Wenn Sie eines dieser Signale sehen — handeln Sie sofort.
Nicht in zwei Wochen. Nicht »wenn wir mehr Informationen haben«. Sondern jetzt.
Denn in den kritischen 100 Tagen ist Zeit Ihr wertvollstes Gut. Jede Woche, die Sie warten, macht das Problem schwerer lösbar.
Ein Beispiel aus der Praxis
Ich habe vor zwei Jahren ein Programm übernommen, das genau in dieser Phase steckte. Tag 75. Stakeholder-Bruch und Ressourcen-Krise gleichzeitig.
Ein Geschäftsbereich hatte innerlich ausgestiegen. Die zugesagten Ressourcen waren nicht verfügbar. Das Programm stand still.
Ich habe drei Dinge gemacht:
Erstens: Ich bin zum Geschäftsbereichsleiter gegangen. Bilateral. Und habe gefragt: »Was müsste anders sein, damit Sie das mittragen können?« Die Antwort: Eine Priorisierungsänderung im Rollout. Die war machbar.
Zweitens: Ich habe die Ressourcen-Krise eskaliert. Zur Führung. Mit der klaren Frage: »Priorisieren wir das Programm oder das Tagesgeschäft?« Die Führung hat sich für das Programm entschieden — und die Ressourcen freigegeben.
Drittens: Ich habe die Governance verschärft. Keine Entscheidung darf mehr als eine Woche offen bleiben. Wenn das Steuergremium nicht entscheiden kann, entscheide ich — und dokumentiere das.
Das Programm ist gerettet worden. Nicht weil die Probleme verschwunden sind — sondern weil sie rechtzeitig adressiert wurden.
Drei Wochen später wäre es zu spät gewesen.
Was das für Sie bedeutet
Wenn Sie gerade ein Programm steuern — oder eines beauftragen — dann fragen Sie sich:
»Sind wir in den kritischen 100 Tagen?«
Wenn ja: Achten Sie auf die drei Wendepunkte. Stakeholder-Bruch, Ressourcen-Krise, Governance-Blockade.
Und wenn Sie eines der Warnsignale sehen — handeln Sie sofort.
Denn die kritischen 100 Tage entscheiden, ob Ihr Programm erfolgreich wird oder scheitert.
Nicht der Go-live. Nicht das Budget. Nicht die Technologie.
Sondern das, was zwischen Tag 30 und Tag 130 passiert.
Über den Autor
Rainer V. Hiller ist Senior Program Manager mit 25 Jahren Erfahrung in der Steuerung komplexer Transformationsprogramme — spezialisiert auf regulierte Umfelder, Organisationsrückbau und Compliance-konforme Cloud-Transformation.
Er ist ab sofort verfügbar für Interim-Mandate.
Kontakt: rainer.hiller@dxb-41.consulting
