xbank Academy für PM
Modul 5 · 25 Minuten

Modul 5 - Krisenmanagement: Eskalation und Abort

Wann werden Notfallprozesse aktiviert, wer entscheidet, welche Abort-Kriterien gelten - aus Aviation auf Projekte übertragen.

Eyecatcher Modul A5: Krisenmanagement — Eskalation und Abort. Das 4-Schritte-Krisenprotokoll STOP, AVIATE, FOR-DEC, COMMUNICATE. Wenn es ernst wird, schlägt Struktur den Reflex.
Das 4-Schritte-Krisenprotokoll: STOP (kontrafaktische Denkpause) → AVIATE (stabilisieren) → FOR-DEC (strukturiert entscheiden) → COMMUNICATE (strukturiert informieren). In der Krise gewinnt nicht, wer am schnellsten handelt — sondern wer zuerst innehält und dann strukturiert vorgeht.

Warum Krisen anders sind

In Krisensituationen versagen die meisten Menschen nicht an mangelndem Wissen, sondern an mangelnder Struktur. Der Stress verengt das Denken, die Wahrnehmung wird selektiv, und instinktiv greifen wir zu den falschen Prioritäten. Piloten trainieren genau für diese Momente — mit klaren Protokollen, die auch unter extremem Druck funktionieren.

Was passiert im Gehirn bei Stress?

Tunnelblick

Der Fokus verengt sich auf ein einzelnes Detail, das Gesamtbild geht verloren. Wir reagieren auf einen Aspekt und übersehen den eigentlichen Vorfall.

Aktionismus

Der Drang, sofort etwas zu tun — auch wenn das Handeln schadet. Lieber falsch handeln als nichts tun. Genau das richtet den meisten Folgeschaden an.

Kommunikations-Overload

Alle reden gleichzeitig, niemand hört zu. Informationen fließen in alle Richtungen, aber kommen nirgendwo strukturiert an. Lärm statt Lagebild.

Hierarchie-Starre

Warten auf Anweisungen statt selbst zu handeln. Wer „eigentlich Bescheid wüsste", schweigt aus Respekt vor der Rangordnung. Wissen erreicht den Entscheider nicht.


Das 4-Schritte-Krisenprotokoll

STOP
30–60 Sek bewusste Denkpause
AVIATE
Stabilisieren — Kontrolle zurück
FOR-DEC
Strukturiert entscheiden
COMMUNICATE
Strukturiert informieren

1. STOP — die kontraintuitive Denkpause

Der kontraintuitivste, aber wichtigste Schritt. Während alles in dir schreit „Tu etwas!”, ist die erste Maßnahme: Innehalten. Diese 30–60 Sekunden verhindern Fehlentscheidungen, die später Stunden kosten. Piloten haben dafür den Ausdruck „Wind the clock” — sie stellen buchstäblich eine Uhr, um sich zum Nachdenken zu zwingen.

✈️ Im Cockpit

„Wind the clock” — Piloten stellen buchstäblich eine Uhr, um sich zum Nachdenken zu zwingen. Keine Checkliste, bevor man die Situation verstanden hat.

💼 Im Projekt

„Bevor wir handeln: Was wissen wir sicher?” Keine E-Mails, keine Anrufe, keine Zusagen — bis die Lage klar ist. Auch nicht „nur kurz” das Team informieren.


2. AVIATE — Stabilisieren

Bevor du das Problem löst, musst du sicherstellen, dass das System stabil ist. Ein Pilot repariert keinen Motor, während das Flugzeug abstürzt — er fliegt erst mal das Flugzeug. Erst Stabilität, dann Lösung.

✈️ Im Cockpit

„Fly the airplane first.” Triebwerksausfall? Erst Flughöhe und Geschwindigkeit stabilisieren. Erst dann Checklisten.

💼 Im Projekt

Krise im Team? Erst Handlungsfähigkeit sichern. Lieferanten-Ausfall? Erst Notlösung für die nächsten 48h. Root Cause kommt später.


3. FOR-DEC — strukturiert entscheiden

Jetzt — und erst jetzt — kommt die strukturierte Entscheidungsfindung. Das FOR-DEC-Modell gibt dir einen klaren Rahmen, auch wenn dein Kopf unter Druck steht. Keine Entscheidung ohne diesen Prozess.

F
Facts
O
Options
R
Risks
D
Decision
E
Execution
C
Check

4. COMMUNICATE — strukturiert informieren

Der häufigste Fehler in Krisen: Sofort alle informieren, bevor man selbst weiß, was los ist. Das Ergebnis: Panik, Gerüchte, Chaos. Kommunikation ist der letzte Schritt — nicht der erste.

✈️ Im Cockpit

Piloten informieren Passagiere erst, wenn sie wissen, was passiert ist und was sie tun. „Ladies and gentlemen, wir hatten ein technisches Problem, das wir gelöst haben…”

💼 Im Projekt

Stakeholder informieren mit: Problem · Auswirkung · Maßnahme · Timeline. Keine Schuldzuweisungen, keine Vermutungen. Klar, kurz, mit nächstem Update-Zeitpunkt.

Das Krisen-Kommunikations-Template

Vier-Zeilen-Lagemeldung

Was: [Kurze, faktische Beschreibung des Problems]
Auswirkung: [Wer/was ist betroffen, mit welchen Konsequenzen]
Status: [Was tun wir gerade — konkret]
Nächstes Update: [Konkrete Uhrzeit, nicht „demnächst”]
✓ Richtig

„Auszahlungs-Service ist seit 14:00 nicht erreichbar. Ca. 200 Filialen betroffen. Notfall-Verfahren aktiviert, Root-Cause- Analyse läuft. Nächstes Update um 15:00.”

✗ Falsch

„Es gibt ein großes Problem!!! Wir wissen noch nicht was genau, aber es ist ernst!!! Ich melde mich, sobald ich mehr weiß.”


Typische PM-Krisen-Szenarien

Vier typische Vorfälle aus dem Bank-Projektalltag, jeweils komplett durch das Protokoll gespielt. Die vier Stufen folgen den Farben aus dem Krisenprotokoll oben (STOP = rot, AVIATE = amber, FOR-DEC = emerald, COMMUNICATE = blau).

Szenario 1 — Schlüsselperson fällt aus

👤 Die Lead-Architektin verlässt das Projekt
Sie kündigt überraschend zwei Wochen vor Go-Live. Sie ist die einzige, die das Migrations-Konzept im Detail kennt.
1
STOP
  • 30–60 Sekunden bewusst durchatmen, keine Hektik-Mails an Team oder Sponsor
  • Frage: Kündigt sie sofort oder zum Monatsende? Welche Fakten sind bestätigt?
  • Frage: Was ist wirklich zeitkritisch — und was fühlt sich nur so an?
2
AVIATE — Stabilisieren
  • Wissens-Transfer sofort priorisieren — die verbleibende Zeit mit ihr gehört dem Migrations-Konzept
  • Backup-Verantwortlichen für ihre offenen Tasks benennen, noch in der gleichen Woche
  • Migrations-Skript zentral dokumentieren lassen, nicht in ihrem Kopf belassen
  • Kein Re-Planning des Gesamtprojekts — erst die akute Lücke schließen
3
FOR-DEC — Entscheiden
  • Facts: offene Tasks, Wissens-Stand, Verträge ihrer Anstellung — schwarz auf weiß
  • Options: intern umverteilen · externe Verstärkung holen · Go-Live verschieben · Migrations-Pfad vereinfachen
  • Risks: pro Option Auswirkung auf Termin / Budget / Qualität abwägen
  • Decision: PL entscheidet — z.B. „Intern + Migrations-Pfad vereinfacht, Go-Live hält”
  • Execution: Aufgaben verteilt, Deadlines fixiert
  • Check: in einer Woche prüfen, ob Wissens-Transfer und Vertretung greifen
4
COMMUNICATE — Informieren
  • Sponsor zuerst — Lage, Entscheidung, Timeline-Risiko. Keine Vor-Schuldzuweisung an die Person
  • Team danach — kein Schock, klarer Plan für die nächsten zwei Wochen
  • Stakeholder zuletzt — Lagemeldung nach Vier-Zeilen-Template, mit Entscheidungsbedarf falls vorhanden
  • Nicht ungefragt — andere Abteilungen oder „interessierte Kreise” bekommen ihr Update über reguläre Kanäle

Szenario 2 — Budget-Überschreitung droht

📉 Forecast zeigt 30% Budget-Überschreitung
In zwei Monaten reißt das Projekt das Budget. Der Sponsor weiß noch nichts.
1
STOP
  • Keine Panik-Eskalation an den Sponsor mit ungeklärten Zahlen
  • Forecast-Zahlen prüfen lassen — ist die Hochrechnung methodisch sauber?
  • Frage: Habe ich die Lage in Zahlen oder nur ein Bauchgefühl?
2
AVIATE — Stabilisieren
  • Nicht-zugesagte Ausgaben sofort einfrieren — keine neuen Bestellungen, keine zusätzlichen Beraterstunden
  • Laufende Verträge sichten: was ist gebunden, was ist optional?
  • Cash-Forecast für die nächsten 4 Wochen quantitativ aufstellen
  • Team bleibt arbeitsfähig — keine Kündigungen, keine Schock-Maßnahmen
3
FOR-DEC — Entscheiden
  • Facts: Verbrauch, Restbudget, Vertragslagen, gesicherter Forecast
  • Options: Scope-Schnitt · Zeit-Streckung · Externe runterfahren · Budget-Nachforderung · Kombination
  • Risks: pro Option — Termin-Effekt, Stakeholder-Reaktion, Folgekosten
  • Decision: z.B. „Scope-Schnitt + 5% Budget-Nachforderung”, schriftlich begründet
  • Execution: wer kommuniziert, wer reduziert Scope, bis wann — alles mit Datum
  • Check: 4-Wochen-Forecast prüft, ob die Maßnahmen Wirkung zeigen
4
COMMUNICATE — Informieren
  • Sponsor mit Optionen, nicht Problem — „Hier ist die Lage, hier sind drei Wege, hier meine Empfehlung”
  • Lenkungsausschuss in der nächsten regulären Sitzung — keine Sondersitzung ohne Zahlen
  • Lieferanten gezielt: Vertragsanpassungen anbahnen (z.B. Volumenreduktion)
  • Team: was bedeutet die Scope-Reduktion konkret für jeden — keine Spekulationen

Szenario 3 — Compliance-Befund kurz vor Release

⚠️ Interne Revision findet einen Stop-Befund
Drei Wochen vor Go-Live entdeckt die zweite Linie einen Compliance-Befund, ohne dessen Behebung kein Release möglich ist.
1
STOP
  • Befund prüfen, nicht widersprechen — was steht da konkret, mit welcher Quelle?
  • Keine Verteidigung an die zweite Linie, bevor du den Befund verstanden hast
  • Den Auditor kurz einladen: lass ihn den Punkt persönlich erklären
2
AVIATE — Stabilisieren
  • Release-Vorbereitung läuft weiter — alle nicht betroffenen Teams arbeiten normal
  • Befund-Bearbeitung in eigene Arbeitsstrecke ausgliedern, mit klarem Owner
  • Frage: ist der Befund auslegungsfähig, oder eine harte Anforderung?
  • Parallel: Risk-Komitee vorab informieren, dass etwas auf sie zukommt
3
FOR-DEC — Entscheiden
  • Facts: Befund-Text, betroffene Komponenten, Aufwand der Behebung, regulatorische Quelle
  • Options: Fix-Forward (Befund vor Release beheben) · Soft-Launch (reduzierter Umfang) · Release verschieben · Befund nachverhandeln
  • Risks: pro Option — Termin-Effekt, regulatorisches Risiko, Reputations-Folgen
  • Decision: z.B. „Fix-Forward, Release-Verschiebung um zwei Wochen”, schriftlich mit Risk-Owner
  • Execution: Aufgaben für die Fix-Strecke, neue Release-Termine, Kommunikationsfahrplan
  • Check: Auditor bestätigt Behebung — sonst neuer Zyklus mit Verschiebungs-Option
4
COMMUNICATE — Informieren
  • Risk-Komitee und Sponsor formell informieren — Lagemeldung mit Optionen und Empfehlung
  • Auditor als Partner, nicht als Gegner — gemeinsamer Lösungsweg, schriftlich
  • Fachbereich über neue Timeline und Auswirkungen auf ihre Arbeitspakete
  • Team transparent: keine Schuldzuweisungen, klarer Plan für die Fix-Strecke

Szenario 4 — Lieferanten-Ausfall

🤝 Externer Dienstleister verzögert die Hardware
Der Lieferant meldet überraschend, dass die zugesagte Hardware nicht zum Stichtag eintrifft.
1
STOP
  • Keine Strafzahlungs-Drohung aus dem Bauch heraus — Vertrag in Ruhe lesen
  • Den Lieferanten zurückrufen lassen: konkrete neue Lieferzeit, mit Begründung
  • Frage: ist es ein Engpass beim Lieferanten oder ein Vorzeichen für ein größeres Problem?
2
AVIATE — Stabilisieren
  • Bestand und Notreserven prüfen — Was haben wir intern oder von Schwesterprojekten verfügbar?
  • Welche Aktivitäten können ohne die Hardware weiterlaufen (z.B. Software-Vorbereitung)?
  • Welche hängen direkt davon ab — und wie lange können sie warten?
  • Einkauf parallel mit Alternativ-Lieferanten sprechen lassen — diskret, ohne Vertragsbruch
3
FOR-DEC — Entscheiden
  • Facts: neue Lieferzeit, Vertragslage, Verfügbarkeit von Alternativen, Auswirkung auf den Projektplan
  • Options: Verschiebung akzeptieren · Alternativ-Lieferant aktivieren · Scope auf verfügbare Hardware reduzieren · Vertragliche Eskalation
  • Risks: pro Option — Termin, Kosten, Vertragsstrafen, Beziehung zum Lieferanten
  • Decision: z.B. „Verschiebung akzeptieren + Vertrag mit Pönale anpassen”, schriftlich
  • Execution: Einkauf führt Verhandlung, PMO passt Plan an, Team passt Sequenz an
  • Check: zwei Wochen später — Liefertermin bestätigt? Auslieferung in Sicht?
4
COMMUNICATE — Informieren
  • Sponsor über Verschiebung und Maßnahmen — mit klarer neuer Timeline
  • Einkauf und Vertragsmanagement — schriftlich, mit Pönale-Auslegung
  • Betroffene Teams — welche Aufgaben warten, welche laufen weiter
  • Lieferanten — formelle Bestätigung des neuen Termins, Eskalationsweg falls erneut verschoben

Weiterführende Ressourcen

Aviation-Hintergrund

  • EUROCONTROL Skybrary — Aviation Safety Knowledge Base, viele Beiträge zu Stressmanagement und Crew Performance unter Druck
  • Threat and Error Management (TEM) — Aviation-Standardmodell, in dem das hier vorgestellte Protokoll eingebettet ist

Verwandte Modelle (zum Vergleich)

  • NIMS (National Incident Management System) — US-Notfall-Framework, bekannt aus Katastrophenschutz und Feuerwehr
  • ITIL Major Incident Management — IT-Service-Management-Variante, näher am IT-Betrieb als am Projektmanagement
  • Business Continuity Management (BCM) — die organisationsweite Klammer um einzelne Krisenprozesse

Vertiefung in der Academy (intern, gleicher Tab)

Kurzer Check

Wissens-Check

Quiz zum Modul

5 Fragen · bestanden ab 60% richtigen Antworten.

1. Warum ist **STOP** der erste Schritt im Krisenprotokoll?

2. Was bedeutet **AVIATE** im Krisenkontext?

3. Welche vier Bausteine gehören in eine **Krisen-Lagemeldung**?

4. Welche Aussage entspricht dem **Krisen-Leitsatz** im PILOT-Framework?

5. Welche drei Merkmale machen einen Vorfall im PILOT-Sinn zu einer **Krise**?

Bitte alle Fragen beantworten, dann wird der Button aktiv.