GooGag – shutterstock.com

In den vergangenen Jahren haben wir Krisenmanagement und den Umgang damit im täglichen Leben erfahren. Die Lehren, was im Großen funktioniert (oder auch nicht) lassen sich mehr denn je auf das Management von IT-Projekten übertragen. Oftmals gelingt es den Betroffenen nicht, sich mit den eigenen Haaren aus dem Morast zu ziehen. Denn Schieflagen entwickeln sich schleichend, oft weitgehend unbemerkt bis es zur Eskalation kommt. Parallelen zur Infektionssituation in einer Pandemie lassen sich ziehen; sie eskalieren, ähnlich wie Infektionen in einer Pandemie.

Mangelhafte Problemkultur als Nährboden für IT-Krisen

Viele Führungskräfte im deutschsprachigen Kulturraum betrachten Probleme nicht als Lernchance sondern oft als Scheitern der eigenen Person und der Verfehlung von Zielen. Fatal wird es, wenn diese Führungskräfte Projektverantwortung tragen. Projektverantwortliche möchten dem Top-Management zeigen, dass Sie ein Projekt “im Griff haben”. Symptomatisch werden in einem IT-Projekt bis zur Deadline grüne, maximal gelbe Ampeln gezeigt. Auf der Tonspur hört man manchmal, dass die Ampel doch dunkelgelb ist. Aber ja nicht rot, denn rot heißt stopp oder man wird beim Überfahren der roten Ampel geblitzt und muss Strafe zahlen.

In der Tat funktioniert diese über Jahre hinweg etablierte und praktizierte Strategie solange gut, wie die Deadline für die Abgabe oder Produktivsetzung von Software noch in weiter Ferne liegt und das Budget nicht aufgebraucht ist. Hier bestehen noch vermeintlich Gestaltungmöglichkeiten, die de facto aber nicht mehr vorhanden sind.

Dann beginnt der Teufelskreis: Je schlimmer die Situation desto mehr wird versucht, unter den Teppich zu kehren. Damit wird die Hürde zu “roten Ampeln” immer höher und Meilensteine werden regelmäßig weiter verschoben, um vermeintlich genug Zeit zu gewinnen, die Probleme zu lösen. Leider fließt bald mehr Zeit in Entschuldigungen und Vertuschung als in die Lösungen der sich immer weiter auftürmenden Probleme.

The road to hell is paved with good intentions!

Ein derartiges, sich immer weiter verzögerndes IT-Projekt mit grünen Ampeln kann ganz leicht vom Top-Management falsch interpretiert werden: Das Projektteam ist im Perfektionismus verfangen und traut sich mit dem vermeintlich guten Produkt nicht an den Markt. In bester Absicht “hilft” die Geschäftsleitung nun, in dem sie einen zügigen Go-Live erzwingt.

Obwohl das Risiko und auch das ungefähre Ausmaß der aus dem Go-Live folgenden Katastrophe absehbar ist, wagt das Projektteam nicht zu wiedersprechen, denn die ehemals kleine “Notlüge” ist inzwischen zu groß. In derartigen Konfliktsituationen ist es ein normaler menschlicher Reflex, Probleme zu verdrängen. “Es wird schon gut gehen” wird zum Mantra und der Vogel Strauß zum heimlichen Projekt-Maskottchen.

Schaden kann über Projektkosten hinausgehen

Natürlich betreffen solche Krisenprojekte i.d.R. IT-Systeme, die zentrale Prozesse der primären Wertschöpfung des Unternehmens unterstützen. Denn es war meist die naturgemäße Komplexität dieser Prozesse, die unterschätzt wurde und das Projekt in Schieflage gebracht hat. Folglich sind nach dem verfrühten Go-Live die ungelösten Probleme sofort für die Kunden sichtbar. Sie stören meist sogar massiv die Erbringung der Leistungen bzw. die Bereitstellung der Produkte, die dem Kunden versprochen wurden. Dabei spielt es keine Rolle, ob es sich beim Kunden um einen internen Auftraggeber oder ein externes Kundenprojekt handelt.

Potenzielle Neukunden, die bereits durch Marketing-Aufwände motiviert wurden, können wegen der IT-Probleme nicht bedient werden oder werden abgeschreckt. Neben den möglicherweise auf lange Zeit verlorenen Neukunden, können sich immer mehr treue Kunden vom Unternehmen abwenden. Im schlimmsten Fall machen sich die verärgerten Kunden auf sozialen Medien Luft, so dass mit dem Imageverlust die Marke des Unternehmens Schaden nehmen kann. Die Konsequenz können langfristige Umsatz- & Gewinneinbrüche sein.

Projektkrisen erfolgreich meistern

Das richtige Vorgehen nach einem katastrophalen Go-Live unterscheidet sich deutlich von einer Projektstabilisierung vor Go-Live. Denn in solchen Fällen bleibt keine Zeit, um nach grundlegenden Ursachen zu forschen. Stattdessen haben sich folgende Schritte in der Praxis bewährt:

1. Problem eingestehen, Stabilisierungsprojekt initiieren & Hilfe organisieren
2. Auswirkungen & Probleme mit den “richtigen” KPIs messbar machen u. objektivieren
3. “Agile” Taskforces aufbauen und für Stabilisierungsmaßnahmen in die Verantwortung nehmen
4. Gut kontrollierte Releases in kurzen Abständen durchführen
5. Nach der Stabilisierung die Ursachen identifizieren und beheben

1. Houston – wir haben ein Problem!
Als allererstes muss das Management erkennen, dass die Krise mehr ist als die Summe der Symptome. Es gilt, so schnell wie möglich die fehlerbehafteten Systeme zu stabilisieren, um den Schaden an der Kundenfront einzudämmen. Nachdem dem Management das Ausmaß der Probleme deutlich wird, geht verständlicherweise meist das Vertrauen in die eigene Mannschaft verloren.

Auch lassen kritische Projektverläufe die beteiligten Personen nicht unberührt – oftmals herrschen auch gegenteilige Meinungen oder Agenden vor. Insofern kann die Lösung nicht von innen kommen, sondern bedarf Unterstützung von außen. Unabhängige externe Unterstützung ist alternativlos. Dabei ist es von größter Bedeutung, einen Projektleiter mit signifikanter Erfahrung in der Stabilisierung von kritischen IT-Projekten zu gewinnen. Dieser sollte von einem schlagkräftigen von Teams aus Experten für die betroffenen Systeme, die Branche und die betroffenen Prozesse flankiert werden.

2. Die richtigen KPIs finden
Erstes Ziel der Analysen ist, so schnell wie möglich die Auswirkungen der fehlerhaften Software auf das operative Geschäft transparent zu machen. Welche Prozesse können nicht abgeschlossen werden und verhindern so Cash-Flow? Idealerweise beantworten ein Top-Management-Dashboard wöchentlich quantitativ bspw. folgende Fragen zu den Auswirkungen der IT-Probleme:

• Anzahl Hotline-Tickets mit der Kundensicht zu den IT-Problemen (Incidents)
• Wieviel neue Verträge mit wieviel Umsatz können nicht abgeschlossen werden?
• Wie viele fällige Rechnungen mit welchem Wert können nicht erstellt werden?
• Welche Leistungen in welchem Wert können nicht erbracht werden?
• Welche Produkte & Services in welchem Wert können nicht ausgeliefert werden?
• Anzahl der Kündiger in unterschiedlichen Deckungsbeitragskategorien?

Dabei sollten die gewählten KPI möglichst unmittelbar auf Verbesserungs-maßnahmen reagieren und gleichzeitig Einzelereignisse.

Nachdem klar wird, wo der höchste wirtschaftliche Schaden entsteht, können die Prozesse priorisiert und die Auslöser der Probleme in der IT näher untersucht werden:

• Code-Fehler (Bugs) im engeren Sinne
• durch Bugs korrumpierte Datenobjekte
• offene Workflows, die aus Prozessunterbrechungen durch Bugs oder korrupte Daten resultieren

All diese “Auslöser” sollten gezählt und ebenfalls im o.g. Top-Management-Dashboard visualisiert werden.

3. Managing the pumps
In gemischten Task-Forces aus Fachbereich, IT und Externen werden in den jeweiligen Prozessen die Fehler mit der größten wirtschaftlichen Auswirkung gesucht und bereinigt. Ideal aufgestellt sind hier Unternehmen, die bereits agile Entwicklungsteams entlang der wichtigsten Wertströme etabliert haben – denn diese entsprechen meist weitgehend einer o.g. Task-Force. In dieser Phase ist es außerdem empfehlenswert, individuelle Werkzeuge zu schaffen, mit denen die Teams Datenprobleme automatisiert beheben können. Auch die (weitere) Automatisierung der Testdatenbeschaffung und der häufigsten Testfälle ist oft ein wichtiger Erfolgsfaktor.

4. DevOps Excellence Now!
Ein wichtiger weiterer Erfolgsfaktor ist, einen schnellen aber dennoch grundsoliden SW-Delivery-Prozess für Releases einzuführen. Falls noch nicht geschehen, muss nun ein Quantensprung im sog. DevOps gemacht werden. Entwickler, die alleine um 4 Uhr nachts im Live-System Programme & Daten ändern, verursachen meist mehr Probleme als sie lösen.

Wegen der erforderlichen kurzen Release-Zyklen lohnt es auch immer, die Testfälle zu überdenken, die unbeabsichtigte Wechselwirkungen von neuem und altem Code aufdecken – dem sog. Regressionstest. Wenn das Unternehmen noch keinen hohen Grad an Testautomatisierung erreicht hat, müssen schnell Test-Center an wichtigen Standorten aufgebaut und bemannt werden. Diese erfordern rigides Management von allen involvierten Testern und Entwicklern.

5. Licht am Ende des Tunnels
Dank der Transparenz durch das Top-Management-Dashboard, mit KPIs für wirtschaftlichen Schaden und quantifizierten Auslösern, wird auch Fortschritt sehr schnell sichtbar. Durch die Priorisierung von Ressourcen auf die wichtigen Probleme stellt sich spürbare Verbesserung der Bottom-Line meist schon nach wenigen Wochen ein. Nach wenigen Monaten ist die Krise dann weitgehend überwunden.

Nun ist der Zeitpunkt gekommen, die grundlegenden Ursachen der Probleme zu analysieren und optimierende Maßnahmen abzuleiten: Von Skills und Organisation über Prozesse und agile Methoden bis zu Tools und Reporting. Es empfiehlt sich nun ebenfalls, ganz nüchtern abzuwägen, ob es besser ist, die verbleiben Schwachstellen der betroffenen Systeme sukzessive punktuell zu adressieren (Refactoring) oder die Systeme komplett zu ersetzen.

Guter Rat ist nicht teuer

Objektivität und Erfahrung sind wesentliche Erfolgsfaktoren für die Stabilisierung einer IT-Krise. Im Vergleich zu den “Kosten der Untätigkeit”, also dem kumulierten verlorenen Cash-Flow, sind die Kosten des Stabilisierungsprojekts verhältnismäßig gering – in Summe eine gute Investition. Übrigens: wer proaktiv vorbauen möchten, der lässt gerade bei größeren Projekten mit auffällig grünen Ampeln den Zustand mit periodischen “Doability Checks” überprüfen. Auf diese Weise kann einer Krise frühzeitig vorgebeugt werden.