Software-Projektrettung: Die ersten 72 Stunden

Wenn eine Führungskraft einer Projektrettung zustimmt, steckt das Software-Projekt meist schon länger in Schwierigkeiten, als irgendjemand offen zugeben wollte. Sobald ein Rettungsteam eintrifft, ist der erste Impuls, sofort mit dem Reparieren anzufangen: Fortschritt vorweisen, Tempo zeigen, beweisen, dass sich der Auftrag gelohnt hat.

Genau dieser Impuls ist falsch. In den ersten 72 Stunden einer Software-Projektrettung geht es nicht darum, das Projekt zu reparieren. Es geht um sechs konkrete Schritte, die in bewusster Reihenfolge passieren müssen, bevor irgendeine Reparatur ungefährlich ist. Ob eine Rettung das Projekt stabilisiert oder alles verschlimmert, hängt fast immer daran, ob diese sechs Schritte richtig gemacht wurden oder ob das Team direkt mit der Behebung angefangen hat, bevor es verstanden hatte, was es da eigentlich behebt.

Schritt 1: Zuerst den Zugang sichern

Wenn Sie nicht unabhängig vom bestehenden Team auf das Produktivsystem, den Deployment-Prozess, die Versionshistorie und den Issue Tracker zugreifen können, können Sie das Projekt nicht zuverlässig diagnostizieren. Liegen alle Zugangsdaten bei einer einzigen Person, etwa bei einem Entwickler, der vielleicht bald geht, oder bei einem Dienstleister, der zum Gegner werden könnte, ist das das erste strukturelle Problem, das Sie lösen müssen, nicht das zehnte.

Den Zugang zu sichern ist keine Verwaltungsaufgabe, die man an jemanden im Team delegiert. Es ist der erste Schritt des Rettungsteams, denn alles Weitere hängt davon ab, den echten Zustand des Systems zu sehen und keine geschönte Version davon. Ein Dienstleister, der den Zugang kontrolliert, kann verzögern, filtern und steuern, was sichtbar wird. Das Rettungsteam braucht direkten Zugang, bestätigt und getestet, bevor die Diagnose beginnt.

Was „bestätigt“ heißt: Das Rettungsteam prüft jeden Zugang selbst, statt sich auf die Meldung des bestehenden Teams zu verlassen, der Zugang sei eingerichtet. Den Zugang zur Versionsverwaltung testet es mit einem echten Pull, den Zugang zur Produktionsumgebung mit einem Lesezugriff. Deployment-Zugangsdaten testet es nach Möglichkeit an einer Umgebung außerhalb der Produktion.

Schritt 2: Belege aus erster Hand sammeln

In den ersten 72 Stunden zählen Belege aus erster Hand: was das Produkt heute in der Produktion tatsächlich tut, nicht was der Statusbericht behauptet. Spielen Sie die kritischen User Journeys selbst durch. Sehen Sie sich die Liste offener Fehler direkt an, statt sie sich zusammenfassen zu lassen. Holen Sie die Deployment-Historie aus der Versionsverwaltung, statt das Team zu bitten, sie zu beschreiben.

Das hat nichts mit Misstrauen gegenüber dem bestehenden Team zu tun. Es liegt an der strukturellen Realität kriselnder Projekte: Die Menschen, die einem scheiternden System am nächsten sind, haben monatelang ihre Vorgesetzten beruhigt und die Probleme umschifft. Ihr Bild vom Zustand des Projekts ist deshalb von allem geprägt, was sie gesagt und getan haben, um es am Laufen zu halten. Ihre Zusammenfassung der Lage spiegelt diese Geschichte wider. Die Belege aus erster Hand tun das nicht.

Diese Unterlagen prüfen Sie in den ersten 72 Stunden: einen Live-Durchgang durch das Produkt in der Produktion, die Liste offener Fehler sortiert nach Schweregrad und Alter, die Deployment-Historie der letzten 30 Tage und jede vorhandene Architekturdokumentation. Nicht, um ihr zu vertrauen, sondern um sie mit dem abzugleichen, was Sie im Code sehen.

Schritt 3: Den kritischen Pfad finden

Ein kriselndes Projekt hat mehr Probleme, als es gleichzeitig lösen kann. Es geht nicht darum, jedes Problem zu katalogisieren, denn dabei entsteht eine Liste, die so lang ist, dass sie lähmt. Es geht darum, den einen Engpass zu finden, der die meiste nachgelagerte Arbeit blockiert: die Abhängigkeit, an der nichts anderes vorbeikommt, den Fehler, der jeden weiteren Test verhindert, den Flaschenhals in der Architektur, von dem jedes Team abhängt.

Der kritische Pfad ist nicht das lauteste Problem, nicht der jüngste Brand und nicht das Problem, an dem das Team am längsten arbeitet. Er ist der eine Engpass, dessen Beseitigung den größten Fortschritt freisetzt.

Um ihn zu finden, brauchen Sie eine Karte, keine Liste. Zeichnen Sie die Abhängigkeiten zwischen allem auf, was passieren muss, oder rekonstruieren Sie sie aus dem, was Sie beobachten können. Der kritische Pfad ist die längste Kette aufeinanderfolgender Abhängigkeiten. An dieser Kette, nicht am dramatischsten Einzelproblem, hat ein Eingriff die größte Hebelwirkung.

Schritt 4: Das Produktionsrisiko eindämmen, bevor irgendjemand etwas verbessert

In den ersten 72 Stunden einer Rettung sollte niemand das Produktivsystem verbessern. Wie stabil das System ist, weiß zu diesem Zeitpunkt niemand. Jede Änderung, auch eine gut gemeinte, bringt zusätzliche Unwägbarkeiten in ein System, dessen Verhalten noch niemand versteht. Der erste Produktionsvorfall, den eine gut gemeinte Verbesserung während der Rettung auslöst, verlängert die Rettung um Wochen und beschädigt genau das Vertrauen, das der Einsatz wiederherstellen sollte.

Der richtige Schritt: einen kontrollierten Änderungsprozess einführen, bevor irgendjemand handelt. Dazu gehören ein festes Zeitfenster für Änderungen an der Produktion, ein verpflichtender, getesteter Rollback-Weg für jedes Deployment und eine namentlich benannte Person, die jede Ausnahme genehmigt. Das ist keine Bürokratie. Es ist das Mindestmaß an Struktur, damit sich die Produktion so vorhersehbar verhält, dass man mit ihr arbeiten kann.

Der Änderungsprozess sollte so schlank wie möglich sein und trotzdem seinen Zweck erfüllen. Bei den meisten Rettungen heißt das: keine Änderung an der Produktion ohne 24 Stunden Vorlauf, außer bei echten Notfällen. Jedes Deployment hat einen getesteten Rollback. Und eine namentlich benannte Person genehmigt jede Ausnahme von diesen beiden Regeln.

Schritt 5: Entscheidungsrechte festlegen

Die häufigste Ursache für Verzögerungen in einem kriselnden Projekt ist kein technisches Problem. Es ist eine Entscheidung, die vor drei Wochen fällig war und immer noch nicht getroffen ist. Entscheidungen stauen sich, weil niemand sicher weiß, wer sie treffen darf. Oder weil die Menschen, die sie treffen könnten, zwischen mehreren konkurrierenden Stakeholdern vermitteln und gelernt haben, dass eine aufgeschobene Entscheidung sicherer ist als eine unpopuläre.

Der richtige Schritt: in den ersten 24 Stunden festlegen, wer dringende Entscheidungen treffen darf, ohne ein Gremium einzuberufen. Das ist ein einziger Name für eine einzige Rolle: die Person, die eine Reduzierung des Umfangs genehmigen, ein Deployment außerhalb des üblichen Zeitfensters freigeben und den Wechsel eines Dienstleisters beschließen kann. Es muss nicht die ranghöchste Person im Raum sein. Es muss jemand sein, der die Befugnis hat und bereit ist, sie auch zu nutzen.

Ohne diesen Namen braucht jede Entscheidung, die schnell fallen muss, ein Meeting, einen Konsens oder eine Eskalation. Jedes davon kostet Tage in einem Zeitplan, der längst keinen Spielraum mehr hat.

Schritt 6: Optimismus durch wenige ehrliche Fakten ersetzen

Was Sie in den ersten 72 Stunden an die Stakeholder kommunizieren, ist kein neuer Liefertermin. Es ist auch kein Rettungsplan. Für beides fehlen Informationen, die erst vorliegen, wenn die ersten fünf Schritte abgeschlossen sind. Wer eines davon zu früh präsentiert, weckt Erwartungen, an denen die Rettung dann gemessen wird.

Der richtige Schritt: das letzte Status-Update, das mit ziemlicher Sicherheit zu optimistisch war, durch wenige konkrete, überprüfbare Fakten ersetzen. Welche Zugänge sind gesichert? Was hat das Rettungsteam selbst gesehen? Wie sieht der Änderungsprozess jetzt aus? Und wann kommt das nächste Update?

Nur Konkretheit stellt das Vertrauen in ein Berichtswesen wieder her, das monatelang optimistische Schätzungen geliefert hat. „Wir haben bestätigten Schreibzugriff auf die Produktionsdatenbank und 47 offene Fehler geprüft, von denen 8 ein Release blockieren“ ist glaubwürdig. „Wir verschaffen uns gerade einen Überblick“ ist es nicht.

Warum die Reihenfolge entscheidend ist

Diese sechs Schritte sind nicht unabhängig voneinander, sie bauen in einer bestimmten Reihenfolge aufeinander auf. Ohne Zugang können Sie keine Belege aus erster Hand sammeln. Ohne diese Belege finden Sie nicht den echten kritischen Pfad. Solange das Produktionsrisiko nicht eingedämmt ist, droht jeder weitere Schritt das System instabiler zu machen. Ohne Entscheidungsrechte enthält Ihre Kommunikation mit den Stakeholdern Zusagen, die Sie nicht halten können.

Die Versuchung ist groß, die Schritte parallel anzugehen: mit den Stakeholdern zu kommunizieren, während die Zugänge noch geklärt werden, und mit der Behebung zu beginnen, während noch Belege gesammelt werden. Genau an dieser Parallelität scheitern Rettungen. Wer mit den Stakeholdern spricht, bevor die Belege vorliegen, sagt etwas zu, dem die Belege später widersprechen. Wer mit der Behebung beginnt, bevor das Produktionsrisiko eingedämmt ist, verursacht Vorfälle, die die Rettung untergraben, bevor sie überhaupt wirken konnte.

Was nach 72 Stunden passiert

Nach 72 Stunden hat eine Rettung, bei der diese sechs Schritte richtig gemacht wurden, vier Dinge in der Hand: bestätigten Zugang zum tatsächlichen Zustand des Systems, Belege aus erster Hand dafür, was wirklich fertig ist und was nicht, einen klar benannten Engpass als Ansatzpunkt mit dem größten Hebel und eine Struktur für Entscheidungsrechte, die handeln kann, ohne ein Gremium einzuberufen.

Das ist das Fundament für einen Rettungsplan. Nicht der Plan selbst, aber die Voraussetzungen, unter denen sich ein verlässlicher Plan aufstellen lässt. Ein Rettungsplan, der vorher entsteht, ist eine Vermutung, verpackt in Projektmanagement-Jargon. Ein Rettungsplan, der danach entsteht, ist eine Diagnose.