12 Warnsignale, dass Ihr Softwareprojekt gerettet werden muss

Die meisten Softwareprojekte, die am Ende gerettet werden müssen, sind nicht in einem einzigen dramatischen Moment dort gelandet. Sie sind schleichend dorthin gerutscht, weil sich nach und nach Warnsignale angehäuft haben. Jedes einzelne wirkte für sich beherrschbar, und zusammen galten sie als normal, bis sie es nicht mehr waren.

Dieser Artikel ist eine strukturierte Bestandsaufnahme dieser Warnsignale, geordnet in drei Kategorien: operativ, technisch und auf Stakeholder-Seite. Dazu kommt eine Anleitung, wie Sie Kombinationen statt einzelner Signale lesen und was Sie tun sollten, wenn Sie die Signale erkennen.

Warum Zählen nicht reicht

Wer eine Liste von Warnsignalen liest, will instinktiv zählen: Wenn wir mehr als X Signale haben, haben wir ein Problem. Diese Sicht übersieht zwei Dinge, die wichtiger sind als die Zahl.

Das erste ist die Verteilung auf die Kategorien. Ein oder zwei Signale innerhalb einer Kategorie sind häufig und erledigen sich oft von selbst. Dass ein Delivery-Team mit Scope Creep kämpft, ist nicht ungewöhnlich, und vielleicht reicht schon ein Gespräch über den Umfang. Treten Signale dagegen gleichzeitig in zwei oder mehr Kategorien auf, ist das genau das Muster, bei dem sich ein Projekt nicht von selbst fängt, weil sich die Probleme gegenseitig verstärken.

Das zweite ist die Dauer. Ein Warnsignal, das vor zwei Wochen aufgetaucht ist und aktiv angegangen wird, bedeutet etwas anderes als dasselbe Signal, das seit drei Review-Zyklen besteht und ungelöst ist. Werten Sie jedes Signal, das seit zwei oder mehr Sprint-Zyklen ungelöst ist, so, als wären es zwei.

Operative Warnsignale

Signal 1: Verschobene Deadlines haben keine Folgen mehr

Jedes Projekt verpasst irgendwann eine Deadline. Das Warnsignal ist nicht die erste verpasste Frist, sondern das, was danach passiert. Wenn auf verpasste Termine ein neuer Termin folgt statt eines Gesprächs über die Ursache, und wenn die neuen Termine genauso vorhersehbar platzen wie die ursprünglichen, funktioniert das Delivery-System nicht mehr. Der Zeitplan ist dann eine Formalität, die das Team pflichtschuldig pflegt, kein Plan, an den noch jemand glaubt.

Woran Sie es erkennen: Fragen Sie den Projektmanager, warum die letzte Deadline verpasst wurde und ob die Ursache behoben ist. Lautet die Antwort ein neues Datum ohne Diagnose, ist das Verschieben strukturell geworden.

Signal 2: Budget und Umfang haben sich voneinander entkoppelt

Steigt in einem Projekt das Budget, während der Umfang gleich bleibt, soll es mehr ausgeben, um dasselbe zu liefern. Das ist ein Kostenproblem. Wächst der Umfang, während das Budget gleich bleibt, soll es für dasselbe Geld mehr liefern. Das ist ein Planungsproblem. Wachsen Budget und Umfang gleichzeitig, hat das Projekt beide Probleme auf einmal, und weder der Sponsor noch das Team weiß genau, was es tatsächlich braucht, um fertig zu werden.

In gesunden Projekten bewegen sich Budget und Umfang gemeinsam: Jede Änderung am einen löst ein ausdrückliches Gespräch über das andere aus. Sind die beiden nicht mehr verknüpft, treibt das Projekt ohne Karte dahin.

Signal 3: Der Umfang wächst, aber niemand streicht etwas

Scope Creep gilt oft als Prozessfehler: Das Team hätte sich stärker wehren sollen. In der Praxis ist er meist das Symptom eines Problems, das weiter vorne liegt. Entweder glauben die Stakeholder nicht, dass das Projekt den vereinbarten Umfang liefert, und packen deshalb mehr dazu, in der Hoffnung, dass wenigstens etwas übrig bleibt. Oder das Team scheut Konflikte und nimmt Ergänzungen an, statt eine Diskussion über Prioritäten zu erzwingen. Oder niemand im Raum hat die Befugnis, Nein zu sagen.

Das Warnsignal sind nicht neue Anforderungen, die sind normal. Das Warnsignal ist ein Backlog, der mit jedem Sprint wächst, während die Spalte „Erledigt“ nicht Schritt hält.

Signal 4: Angefangene Arbeit stapelt sich, statt ausgeliefert zu werden

Viel Work in Progress ist einer der verlässlichsten Frühindikatoren für ein Projekt in Schwierigkeiten. Sind viele Aufgaben gleichzeitig in Arbeit, steigt der Aufwand für Kontextwechsel, die Integration wird komplexer, und dem Team fehlt das Feedback, das nur eine Auslieferung bringt. Ein Team mit zwanzig offenen Aufgaben kommt meist deutlich langsamer voran als ein Team mit fünf, selbst wenn das Team mit den zwanzig Aufgaben länger arbeitet.

Prüfen Sie das Verhältnis zwischen Aufgaben in Arbeit und Aufgaben, die im letzten Sprint abgeschlossen wurden. Liegen die offenen Aufgaben dauerhaft über den abgeschlossenen, ist der Arbeitsfluss zusammengebrochen.

Technische Warnsignale

Signal 5: Die Zahl der Fehler steigt, während das Team an neuen Features arbeitet

Wächst der Berg offener Fehler, während das Team weiter neue Funktionen baut, ist das ein Zeichen für technische Schulden, die sich aufschaukeln. Das Team baut auf einem instabilen Fundament und vergrößert die Instabilität mit jedem Sprint. Dieses Muster beschleunigt sich meist: Neue Features bringen neue Fehler, bestehende Fehler wirken auf unvorhergesehene Weise mit neuem Code zusammen, und das Team verbringt einen immer größeren Teil jedes Sprints mit Fehlersuche statt mit Lieferung.

Lassen Sie sich die Liste der offenen Fehler nach Alter sortiert zeigen. Sind kritische und schwerwiegende Fehler seit mehr als ein oder zwei Sprints ungelöst, steckt das Projekt technisch in der Krise.

Signal 6: Der Fertigstellungsgrad stagniert trotz laufender Arbeit

„90 % fertig“ ist die gefährlichste Zahl in einem Softwareprojekt. Meldet ein Projekt über mehrere Sprints hinweg 80 bis 90 % Fertigstellung, ist es fast nie in einem sinnvollen Sinne zu 80 bis 90 % fertig. Im letzten Abschnitt eines Projekts ballt sich der größte Teil des echten Risikos: Integration, Sicherheit, Performance unter realer Last, Abnahme durch die Nutzer, Betriebsbereitschaft. Teams können offiziell monatelang bei 90 % stehen, während sie Probleme abarbeiten, von denen sie vorher nichts wussten.

Ein Projekt, das seit drei Sprints zu 90 % fertig ist, ist nicht fast fertig. Es steckt im schwierigsten Teil des Projekts, und das Reporting bildet diese Realität nicht mehr ab.

Fragen Sie deshalb nicht nach dem Fertigstellungsgrad, sondern nach dem, was sich vorführen lässt: Welche konkrete Funktion können Sie jetzt sofort in einer Live-Umgebung laufend zeigen, die beim letzten Sprint Review noch nicht lief?

Signal 7: Änderungen in einem Bereich legen ganz andere Bereiche lahm

Wenn eine Änderung im Frontend die Verarbeitung im Backend stört oder ein Bugfix in einem Modul Fehler in drei anderen auslöst, hat die Architektur vermutlich versteckte Kopplungen angesammelt: Abhängigkeiten zwischen Komponenten, die im ursprünglichen Design nicht sichtbar waren und sich ohne sorgfältige Analyse auch im Code nicht erkennen lassen. Dieses Muster macht jede Änderung teurer und riskanter, als sie sein müsste.

Der Test: Fragen Sie das Team nach den letzten drei Hotfixes oder dringenden Änderungen und verfolgen Sie, was dadurch sonst noch kaputtgegangen ist. Fallen in den Antworten Sätze wie „Wir wissen nicht genau, warum das betroffen war“ oder „Damit, dass das kaputtgeht, haben wir nicht gerechnet“, verbirgt die Architektur Abhängigkeiten, die das Team nicht versteht.

Signal 8: Nur eine einzige Person kann sicher in Produktion deployen

Liegt das Wissen über das Deployment bei einem einzigen Entwickler, einem einzigen Mitarbeiter des Dienstleisters oder einem einzigen Tech Lead, hat das Projekt einen Single Point of Failure. Das ist kein technisches Risiko, sondern ein geschäftliches. Geht diese Person, fällt sie aus oder wird sie zum Gegenspieler, ist die Stabilität der Produktion sofort gefährdet.

Fragen Sie, wer genau den aktuellen Build morgen in Produktion bringen könnte, wenn die übliche Person nicht verfügbar wäre. Lautet die ehrliche Antwort „Niemand sonst könnte das sicher“, ist das ein Warnsignal, das vor allem anderen gelöst werden muss.

Warnsignale auf Stakeholder-Seite

Signal 9: Statusmeetings sind zum Theater geworden

Wenn Stakeholder in Statusmeetings keine unbequemen Fragen mehr stellen, wenn Woche für Woche dieselbe positive Darstellung unwidersprochen bleibt und wenn die echten Gespräche nach dem Meeting auf dem Flur stattfinden statt im Meeting selbst, dann erfüllt das Statusreporting seinen Zweck nicht mehr. Es ist zu einem Ritual geworden, das alle im Raum vor dem Unbehagen eines ehrlichen Gesprächs schützt.

Das Warnsignal sind nicht ein oder zwei Meetings ohne schwierige Fragen. Es ist ein anhaltendes Muster, bei dem das Meeting dazu dient, den Plan zu bestätigen, statt ihn zu hinterfragen.

Signal 10: Schlechte Nachrichten kommen spät und bereits eskaliert an

Wenn Eskalationen fix und fertig auf dem Tisch landen, wenn also ein Problem, das auf Teamebene seit Wochen bekannt ist, erst jetzt den Sponsor erreicht, ist die Informationskette gerissen. Entweder hält das Team Eskalieren für riskant, oder die Ebenen zwischen Team und Sponsor filtern Informationen heraus, die schneller fließen müssten.

Fragen Sie den Sponsor: Wenn Sie erfahren, dass etwas schiefläuft, wie lange weiß das Team in der Regel schon davon? Ein beständiges Muster verspäteter Eskalation gehört zu den verlässlichsten Vorzeichen für ein Projekt, das mehr Probleme hat, als seine Statusberichte zeigen.

Signal 11: Das Vertrauen zwischen Stakeholdern und Delivery-Team bröckelt

Schwindendes Vertrauen in einem Softwareprojekt ist meist nicht die Folge eines einzelnen Ereignisses, sondern angesammelter Enttäuschungen: verpasste Deadlines, unvollständige Features, unzuverlässige Schätzungen. Ist der Vertrauensverlust einmal da, entsteht eine Dynamik, die sich selbst verstärkt. Stakeholder erhöhen Kontrolle und Druck, das steigert Stress und Abwehrhaltung im Team, und das erzeugt noch mehr von dem defensiven Reporting, das das Vertrauensproblem überhaupt erst ausgelöst hat.

Das Signal wird selten offen ausgesprochen. Es zeigt sich daran, dass Stakeholder die Angaben des Teams selbst nachprüfen, dass Sponsoren an Standups teilnehmen, die sie früher delegiert hatten, und dass sich der Ton in Projektgesprächen insgesamt verschiebt: weg von Zusammenarbeit, hin zu einem reinen Geschäftsverhältnis.

Signal 12: Schlüsselpersonen gehen oder ziehen sich innerlich zurück

Fluktuation und Rückzug unter den fähigsten Leuten eines Projekts sind Spätindikatoren. Wenn sie sichtbar werden, steckt das Projekt meist schon eine Weile in der Krise. Die besten Leute in einem angeschlagenen Projekt erkennen in der Regel früher als die Stakeholder, was passiert, und sie haben Alternativen. Mit ihrem Weggang verschwinden das Wissen über das Projekt und der verbliebene Schwung, die es oft als Einziges noch in Bewegung halten.

Eine subtilere Form dieses Signals ist der innere Rückzug: Die erfahrenen Leute im Projekt sind noch da, sprechen aber keine Probleme mehr an, schlagen keine Lösungen mehr vor und ergreifen keine Initiative mehr. Sie haben für sich entschieden, dass das Projekt nicht mehr zu retten ist, und warten nur noch auf die Bestätigung.

Wie viele Signale sind zu viele?

Eine sinnvolle Schwelle ist keine bestimmte Zahl, sondern eine Kombinationsregel. Sehen Sie zwei Signale aus verschiedenen Kategorien, etwa ein operatives und eines auf Stakeholder-Seite, behandeln Sie das als Muster und nicht als zwei getrennte Probleme. Sehen Sie drei beliebige Signale, egal aus welcher Kategorie, ist eine unabhängige Prüfung angebracht. Sehen Sie Signale in allen drei Kategorien gleichzeitig, wird sich das Projekt nicht von selbst erholen.

Was tun, wenn Sie diese Signale erkennen?

Der häufigste Fehler ist der Versuch, Warnsignale innerhalb des bestehenden Teams und der bestehenden Berichtswege anzugehen, also mit denselben Leuten und derselben Informationskette, die das Problem hervorgebracht haben, die Diagnose zu stellen und es zu beheben. Die Menschen, die dem Projekt am nächsten sind, haben die meisten Informationen. Sie haben aber auch, bewusst oder unbewusst, den stärksten Anreiz zu glauben, dass der Plan, den sie selbst gebaut haben, immer noch der richtige ist.

Eine unabhängige Bewertung ist genau dafür da, die Fragen zu beantworten, die sich von innen nicht verlässlich beantworten lassen: Was ist wirklich fertig und vorführbar, wie hoch ist das tatsächliche Restrisiko, und lohnt es sich, das Projekt in seiner jetzigen Form fortzuführen? Nur so bekommen Sie eine Empfehlung von jemandem, der kein Interesse daran hat, dass die Antwort „weitermachen“ lautet.