Foto: 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.
- 1. Unklare Arbeitslast
Bryan Fagman vom Anbieter Micro Focus sagt, dass viele Projekte an einem nicht klar umrissenen Arbeitsaufwand scheitern. Schleichen sich hier Unschärfen ein, leidet das ganze Projekt. Im schlimmsten Fall bleibt undefiniert, wann es überhaupt abgeschlossen ist. Fagman mahnt deshalb an, Ziele im Dialog mit den Kunden klar zu benennen. - 2. Undefinierte Erwartungen
Alle Beteiligten müssen von Beginn an wissen, welche Anforderungen ein Projekt stellt und welche Erwartungen zu erfüllen sind – sonst droht ein Fiasko. Tim Garcia, CEO des Providers Apptricity, nennt zwei entscheidende Dinge, die alle Team-Mitglieder vorab wissen sollten: was getan wird und wie man weiß, wann das Projekt abgeschlossen ist. „Ohne eine dokumentierte Vereinbarung, die Antworten auf diese beiden Fragen liefert, ist ein Projekt von Anfang an in Gefahr“, sagt Garcia. - 3. Fehlende Management-Unterstützung
Die Unterstützung aus der Firmenspitze sollte unbedingt gesichert sein. Befindet man sich dahingehend mit der Chef-Etage nicht in Einklang, mindert das die Erfolgsaussichten beträchtlich, meint Brad Clark vom Provider Daptiv. - 4. Methodik nach Schema F
Im Projekt-Management wird gemeinhin mit standardisierten Schlüsselaufgaben und Leistungen gearbeitet. Darin lauert nach Einschätzung von Robert Longley, Consultant beim Beratungshaus Intuaction, aber auch eine Gefahr. Die Standard-Ansätze seien meist auf Projekte einer bestimmten Größe ausgerichtet. Sie passen möglicherweise nicht mehr, wenn man sich an größere Projekte als in der Vergangenheit wagt. - 5. Überlastete Mitarbeiter
„Team-Mitglieder sind keine Maschinen“, sagt Dan Schoenbaum, CEO der Projekt-Management-Firma Teambox. Projekte können auch daran scheitern, dass Mitarbeiter mit Arbeit überfrachtet werden. Vermeiden lässt sich das, indem man sich vorab ein klares Bild über die Stärken der Team-Mitglieder macht und auf eine sinnvolle Verteilung der Aufgaben achtet. - 6. Ungeteiltes Herrschaftswissen
Projekte leben davon, dass Informationen nicht monopolisiert, sondern miteinander geteilt werden. Das geschieht oft dann nicht, wenn Ergebnisse erst nach langer Anlaufzeit geliefert werden müssen. Tim Garcia von Apptricity rät deshalb dazu, Projekt in kurze Phasen einzuteilen. An deren Ende sollte es jeweils Resultate geben, mit denen das ganze Team weiterarbeiten kann. - 7. Unklare Entscheidungsfindung
Im Verlauf eines Projektes sind Änderungen der ursprünglichen Roadmap oft unvermeidbar. Es sollte beim Change Management aber klar dokumentiert werden, wer wann was geändert hat und wie die neue Marschrichtung aussieht. - 8. Fehlende Software
Exel-Spreadsheets nötigen Projekt-Manager zu manuellen Korrekturen und führen oft zu Problemen bei der Status-Aktualisierung. Insofern ist es befreiend, mit Project Management Software zu arbeiten, die für automatische Updates sorgt und von lästigen manuellen Berichten entlastet. Dazu rät Brian Ahearne, CEO des Anbieters Evolphin Software. - 9. Gefahr des Ausuferns
Change Requests sind alltäglich im Projekt-Leben, aber sie haben leider oft einen unerfreulichen Nebeneffekt: den Hang, Fristen und Budget-Rahmen immer weiter auszudehnen und auf Dauer zu Demotivation und Frust auf allen Seiten zu führen. Um dieser Entwicklung Einhalt zu gebieten, sind neben klaren Zielvorgaben auch tägliches Monitoring und ein definierter Prozess für gewünschte Veränderungen sinnvoll. Das empfiehlt in jedem Fall Sandeep Anand, der beim Software-Entwicklungshaus Nagarro für Project Governance verantwortlich ist. - 10. Nicht "Nein" sagen können
Im Sinne des Unternehmens sei es manchmal nötig, Anfragen abzulehnen, sagt Markus Remark vom Provider TOA Technologies. Gut sei es deshalb zu wissen, wie man "nein" sagt. Am besten habe man für solche Fälle auch gleich eine konstruktive alternative Lösung parat. - 11. Mangelnder Zusammenhalt
Projektarbeit ist Team-Arbeit. In der Praxis gerieren sich manche Projekt-Teams aber wie in Eifersüchteleien gefangene Sportmannschaften ohne Erfolg, beobachtet Berater Gordon Veniard. Der Fokus auf das eigentliche Ziel gehe verloren. Stattdessen beschuldigen sich Grüppchen gegenseitig, für Probleme und schlechte Leistungen verantwortlich zu sein. Um das zu verhindern, ist Führung durch den Projekt-Manager gefragt. Und der sollte es verstehen, sein Team mitzunehmen und in Entscheidungen einzubinden. Ohne Kommunikation sei das Desaster programmiert, so Hilary Atkinson vom Provider Force 3. - 12. Vergessener Arbeitsalltag
Hilary Atkinson hat nach noch einen weiteren Kommunikationstipp parat: Projekt-Manager sollten nicht vergessen, ihre alltäglichen Aufgaben zu erledigen. Wer als Verantwortlicher keine Meeting-Termine verkündet, Status-Berichte vergisst und E-Mails unbeantwortet lässt, riskiert unnötige Verzögerungen. - 13. Zu häufige Meetings
Meetings, in denen der Status Quo besprochen wird, können nerven – vor allem dann, wenn sie zu oft stattfinden oder zu lange dauern. Wichtige Informationen lassen sich durch Collaboration Tools häufig besser an die Team-Mitglieder bringen, meint Liz Pearce, CEO des Providers LiquidPlanner. Ihr Tipps: Meeting auf die Entscheidungsfindung beschränken. In ihrem Unternehmen gebe es lediglich zweimal in der Woche ein Treffen, um neue Aufgaben zu verteilen und Prioritäten zu definieren. - 14. Gut genug ist nicht immer gut
Sergio Loewenberg vom IT-Beratungshaus Neoris macht Nachlässigkeiten in der Qualitätssicherung als Problem aus. Es sei günstiger, Fehler zu vermeiden anstatt Geld und Zeit ins Ausmerzen ihrer negativen Folgen stecken zu müssen. Wer auf hohe Qualitäts-Standards achte, vermeide späteres Nacharbeiten und die Gefahr eines schlechten Rufes. - 15. Nicht aus Fehlern lernen
Liz Pearce mahnt außerdem an, mit Hilfe entsprechender Tools eine mehrstündige Analyse nach Ende des Projektes durchzuführen. Nur Teams, die sich des ständigen Lernens verschreiben, seien dazu in der Lage, die Fehler der Vergangenheit in der Zukunft zu vermeiden. - 15 Fehler beim Projektmanagement
Es gibt unzählige Wege, ein IT-Projekt an die Wand zu fahren. Unsere amerikanische Schwesterpublikation CIO.com hat 15 davon gesammelt – und verrät dankenswerterweise auch, wie man die Probleme beheben kann. Diese Tipps sind in der Bilderstrecke zu finden.
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.
Lesetipp: Wie Sie Projektteams erfolgreich führen
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:
Problem eingestehen, Stabilisierungsprojekt initiieren & Hilfe organisieren
Auswirkungen & Probleme mit den "richtigen" KPIs messbar machen u. objektivieren
"Agile" Taskforces aufbauen und für Stabilisierungsmaßnahmen in die Verantwortung nehmen
Gut kontrollierte Releases in kurzen Abständen durchführen
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.
Lesetipp: Die 7 schlimmsten KPI-Sünden
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.
Lesetipp: Wie Anwender DevOps einsetzen
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.
- CI/CD
Continuous Integration beziehungsweise Continuous Delivery wird oft als essenzieller Teil einer erfolgreichen DevOps-Strategie gesehen. Meist ist die Kombination beider Methoden gemeint, um schneller stabilen Code ausliefern zu können. - Continuous Integration (CI)
Dieser Begriff beschreibt eine Methode, um fortlaufend Veränderungen im Code in den Hauptzweig zu integrieren, die anschließend automatisiert getestet werden. Damit erhalten Entwickler innerhalb weniger Minuten Rückmeldung, ob der Build die Qualitätsansprüche erfüllt. Zudem vermeiden sie den hohen Aufwand, der entsteht, wenn sämtliche Code-Anpassungen auf einmal am Tag der Veröffentlichung in den Release-Zweig integriert werden müssen. - Continuous Delivery (CD)
Dies beschreibt die automatisierte Auslieferung von Anwendungs-Code an diverse Infrastruktur-Umgebungen wie Entwicklungs-, Test, Integrations- und Produktivumgebungen. - Integrated Developer Environments (IDE)
Integrierte Entwicklungsumgebungen sind Anwendungen, die dabei helfen, Anwendung zu bauen. Darin sind normalerweise ein Code-Editor, Compiler, Debugger und Tools zur Build-Automatisierung enthalten, um zeitaufwändige, händische Aufgaben aus der Entwicklung zu entfernen. - Software Development Lifecycle (SDLC)
Es gibt verschiedene Vorgehensmodelle zur Softwareentwicklung, die unterschiedliche Phasen des Software-Lebenszyklus definieren. Die für DevOps verwendeten wiederholbaren Modelle verwenden meist ein kreisförmiges Schema, in denen oft die Stufen Analyse („Was soll die App können?“), Entwurf/Entwicklung, Implementierung, Test und Wartung/Evaluation enthalten sind. - Static Application Security Testing (SAST)
SAST ist eine Methode, um die Sicherheit von Anwendungen während der Entwicklung zu testen. Dabei wird der Quellcode „von innen heraus“ auf Schwachstellen und Bugs hin analysiert. Da der Code für die Analyse nicht kompiliert sein muss, kann SAST sehr früh im Entwicklungszyklus eingesetzt werden, um so Fehler bereits in der Entstehung zu beseitigen. - Regressionstest
In einem Regressionstest werden Testfälle wiederholt, um sicherzustellen, dass Modifikationen in bereits getesteten Teilen der Software keine neuen Fehler („Regressionen“) verursachen.
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. (bw)