Softwareprojekt in Schieflage: Woran Sie erkennen, ob es noch zu retten ist

Irgendwo zwischen der vierten verpassten Deadline und der Board-Sitzung, in der endlich jemand fragt: „Sollen wir das weiter finanzieren?“, kommt jedes festgefahrene Softwareprojekt an denselben Punkt. Die Führung muss klären, ob sie weiter für ein Projekt zahlt, das nicht liefert. Und entscheiden sollen meist ausgerechnet die Menschen, die dem Projekt am nächsten sind und sich einen Irrtum am wenigsten leisten können.

Ob ein Softwareprojekt gerettet werden soll, hängt nicht an einer Frage, sondern an sechs voneinander unabhängigen Fragen (zu Geschäftswert, Restarbeit, Architektur, Leistungsfähigkeit des Teams, Dienstleisterrisiko und Time to Market), die erst zusammen Sinn ergeben. Einzeln beantwortet wirkt jede davon noch verkraftbar. Zusammen zeigen sie, was Sie vor sich haben: ein Projekt, das sich zu retten und zu stabilisieren lohnt, eines, das einen teilweisen Neubau braucht, eines, bei dem Team oder Dienstleister wechseln müssen, oder eines, das Sie stoppen sollten, bevor es mehr kostet, als es je einbringen kann.

Genau das soll eine Projektrettung klären: nicht, ob ein Team irgendwann fertig wird, sondern ob die Fertigstellung überhaupt noch die richtige Entscheidung ist. Im Folgenden finden Sie das Modell, mit dem Sie diese Entscheidung auf Belege statt auf Optimismus stützen. Nach derselben Struktur arbeitet auch eine unabhängige Bewertung zur Projektrettung, bevor sie einen Weg empfiehlt.

Warum die Beteiligten diese Entscheidung nicht treffen können

Ein scheiterndes Softwareprojekt kündigt sich selten mit einem einzigen dramatischen Ereignis an. Es zeigt sich in einer langsam wachsenden Reihe von Statusberichten, die schon Monate unzuverlässig waren, bevor es jemand laut ausgesprochen hat. Die ehrliche Antwort auf die Frage „Ist dieses Projekt noch zu retten?“ kommt selten aus dem Projekt selbst. Nicht, weil jemand lügt. Sondern weil jeder, der direkten Einblick in das Projekt hat, auch einen Grund hat, bewusst oder unbewusst, den Plan zu verteidigen, den er selbst aufgestellt hat.

Der Projektmanager, der achtzehn Monate in die Roadmap gesteckt hat, will glauben, dass die Roadmap noch funktioniert. Der Dienstleister, der nach Aufwand abrechnet, hat ein direktes finanzielles Interesse daran, dass der Auftrag genau so weiterläuft wie bisher. Das interne Team, das die Architektur entworfen hat, kann kaum unbefangen zu dem Schluss kommen, dass ausgerechnet die Architektur das Problem ist. Und der Sponsor aus der Geschäftsführung, der das Projekt vor dem Board vertreten hat, hat das stärkste Motiv von allen: Einzugestehen, dass das Projekt gestoppt werden sollte, kostet ihn persönlich so viel wie niemanden sonst im Raum.

Das macht niemanden unehrlich. Es macht die Berichte aber unzuverlässig, und zwar in eine bestimmte, vorhersehbare Richtung: zu optimistisch. „Wir sind zu 90 % fertig“ ist der häufigste Satz in einem Softwareprojekt in Schieflage. Fast immer misst er den geleisteten Aufwand, nicht das verbleibende Risiko. Im letzten Abschnitt eines Softwareprojekts ballt sich meist der Großteil des Risikos: Integration, Sicherheitsprüfung, Deployment, Performance unter realer Last, Abnahme durch die Nutzer und Betriebsbereitschaft. Ein Team kann monatelang „90 % fertig“ melden, ohne ein einziges Mal zu lügen, denn in den restlichen 10 % lag die eigentliche Schwierigkeit von Anfang an.

„Wir sind zu 90 % fertig“ misst fast immer den geleisteten Aufwand, nicht das verbleibende Risiko. Im letzten Abschnitt eines Softwareprojekts ballt sich meist der Großteil des Risikos.

Deshalb muss die Entscheidung über eine Rettung auf Belegen beruhen, die unabhängig von den Menschen erhoben wurden, die den aktuellen Plan aufgestellt haben. Nicht auf einem weiteren Statusbericht aus derselben Berichtskette, aus der schon die letzten sechs kamen.

Was „Ist dieses Projekt noch zu retten?“ wirklich bedeutet

Bevor Sie ein Modell anwenden, lohnt es sich, die Frage genau zu fassen. Sie lautet nicht: „Wird das Team irgendwann fertig?“ Mit genug Zeit und Geld lässt sich technisch fast jedes Projekt abschließen. Die eigentliche Frage ist wirtschaftlich: Bringt die Fertigstellung dieses Projekts in seiner jetzigen Form, mit dem jetzigen Team oder Dienstleister und auf der jetzigen Architektur ab heute noch mehr Wert, als sie kostet?

Dieser Perspektivwechsel ist wichtig, weil er die beiden Kräfte ausschaltet, die die meisten Rettungsentscheidungen verzerren: versunkene Kosten und Hoffnung. Entschieden wird über die verbleibenden Kosten im Verhältnis zum verbleibenden Wert, bewertet von jemandem, der nichts davon hat, wenn die Antwort Ja lautet.

Darin liegt der Kern einer Projektrettung: Gerettet wird nicht der Code, sondern die Entscheidungsfindung rund um das Projekt. Sechs Faktoren bestimmen die Antwort: Geschäftswert, Restarbeit, Architektur, Leistungsfähigkeit des Teams, Dienstleisterrisiko und Time to Market. Jeder wird anhand eigener Belege geprüft. Keiner sagt Ihnen allein, ob Sie weitermachen sollten. Zusammen weisen sie klar auf eines von vier Ergebnissen.

Das Entscheidungsmodell mit sechs Faktoren

1. Geschäftswert: Hat dieses Projekt noch eine Daseinsberechtigung?

Wenn der ursprüngliche Business Case nicht mehr trägt, weil sich der Markt verschoben hat, die Zusage an den Kunden sich geändert hat oder die Kosten bis zur Fertigstellung inzwischen jeden plausiblen Ertrag übersteigen, spielt kein anderer Faktor in diesem Modell eine Rolle. Ein technisch gesundes Projekt ohne tragfähigen Business Case sollte trotzdem gestoppt werden.

Jedes Softwareprojekt beginnt mit einem Business Case: einer Marktchance, einer Kosteneinsparung, einer Anforderung aus dem Wettbewerb, einer Zusage an einen Kunden. Projekte scheitern selten, weil dieser Business Case am ersten Tag falsch war. Sie scheitern, weil ihn irgendwann niemand mehr geprüft hat, während das Projekt monatelang Budget verbrauchte, in der Annahme, er gelte noch.

Der entscheidende Test ist leicht formuliert und unbequem in der Anwendung: Würde man Ihnen dieses Projekt heute vorlegen, zu den aktuellen Kosten bis zur Fertigstellung und ohne jede Vorgeschichte, würden Sie die Investition freigeben? Nüchtern und nach der Sache beurteilt, und nicht deshalb, weil Sie sich versunkene Kosten nicht eingestehen wollen. Die bereits ausgegebenen 400.000 $ ändern nichts daran, ob die nächsten 150.000 $ gut angelegt sind. Das entscheiden allein die verbleibenden Kosten und der verbleibende Wert. Für ein internes Team ist das die schwierigste Einschätzung über das eigene Projekt. Wer zugibt, dass der Business Case nicht mehr trägt, gibt beinahe zu, dass das Projekt schlecht geführt wurde, selbst wenn sich in Wahrheit der Markt aus Gründen verschoben hat, die niemand in der Hand hatte.

• Hat sich die ursprüngliche Annahme über den Markt bestätigt?
• Hat ein Wettbewerber die Funktion, die dieses Projekt liefern sollte, schon auf den Markt gebracht?
• Gibt es die Kundenzusage oder vertragliche Verpflichtung, mit der die Ausgaben begründet wurden, noch?
• Sind die Kosten bis zur Fertigstellung schneller gestiegen als der Wert der Fertigstellung?

2. Restarbeit: Was ist wirklich fertig, und was wird nur als fertig gemeldet?

Ersetzen Sie die Prozentangabe zum Fertigstellungsgrad durch eine Liste von Meilensteinen, die sich vorführen lassen. „90 % fertig“ beschreibt den geleisteten Aufwand, nicht das verbleibende Risiko, und das Risiko ballt sich fast immer im letzten Abschnitt.

Fortschrittsberichte in Prozent scheitern aus einem strukturellen Grund, nicht aus Unehrlichkeit: Sie messen das Falsche. Ein Team, das 90 % des geplanten Codes geschrieben hat, hat damit nicht 90 % des Risikos hinter sich. Integration zwischen Systemen, Sicherheitsprüfung, Performance unter realer Last, Automatisierung des Deployments, Abnahme durch die Nutzer und Betriebsbereitschaft kommen meist zuletzt, und genau dort steckt in der Regel die echte Unsicherheit. Ein Projekt kann sechs Monate am Stück „zu 90 % fertig“ sein, weil die restlichen 10 % nie 10 % der Schwierigkeit waren.

Die Lösung ist keine bessere Prozentzahl, sondern eine ganz andere Frage: Was können Sie jetzt gerade tatsächlich vorführen? Verlangen Sie eine Live-Umgebung, keine Folie. Fragen Sie, was ein Nutzer dort heute tun kann, nicht, was laut Backlog geplant ist. Teilen Sie den Umfang ehrlich in drei Kategorien ein: nachweislich fertig, teilweise fertig mit einer konkreten Liste des Rests, und noch nicht begonnen. Die Lücke zwischen dieser Liste und dem letzten Statusbericht sagt Ihnen das meiste von dem, was Sie wissen müssen.

• Kann das Team eine funktionierende Demo in einer Umgebung zeigen, für die Sie nicht zwei Wochen vorher einen Termin vereinbaren mussten?
• Wie sieht die Liste der offenen Fehler aus, und wie viele davon sind als kritisch oder hoch eingestuft?
• Gibt es einen funktionierenden, wiederholbaren Weg zum Deployment, oder braucht jede Auslieferung den Handgriff einer bestimmten Person?
• Welche Integrationspunkte wurden noch nicht mit echten Daten getestet?
• Gibt es für den verbleibenden Umfang eine schriftliche Definition of Done, oder ist „fertig“ noch Auslegungssache?

3. Architektur: Trägt das Fundament den Rest?

Die Frage ist nicht, ob der Code perfekt ist. Das ist kaum eine Codebasis in Produktion. Die Frage ist, ob sich eine Änderung umsetzen, testen und ausliefern lässt, ohne dass ein Entwickler vorher das gesamte System verstehen muss. Lautet die Antwort Nein, kostet jedes verbleibende Feature mehr, als es sollte, egal wie viele Leute Sie dazuholen.

Architekturprobleme zeigen sich selten als einzelner katastrophaler Fehler. Sie zeigen sich als Muster: Jede Änderung dauert länger als nötig, jeder Fix erzeugt an ganz anderer Stelle einen neuen Fehler, und nur das Team, das das System gebaut hat, kann es gefahrlos anfassen. Dieses Muster ist das Signal, nicht ein einzelner Bugreport. Hier sind technische Schulden strukturell geworden: kein Backlog-Eintrag mehr, den man einplant, sondern eine Bremse für alles, was das Team als Nächstes vorhat.

Der praktische Test heißt Testbarkeit. Kann ein Entwickler eine Änderung vornehmen und prüfen, dass sie sicher ist, ohne vorher zu verstehen, wie das gesamte System zusammenhängt? Wenn ja, kann die Architektur den verbleibenden Umfang wahrscheinlich tragen, so unvollkommen sie auch ist. Wenn nein, dauert jedes Feature auf der Roadmap länger als geschätzt, kostet mehr als budgetiert und bringt mehr Fehler mit als das vorige, ganz gleich, wie viele Entwickler zusätzlich daran arbeiten. Wer einem Projekt mit ungelösten Architekturschulden mehr Leute gibt, erhöht nicht den Durchsatz. Er erhöht den Abstimmungsaufwand auf einem ohnehin wackligen Fundament.

• Wie oft deployt wird und wie oft ein Deployment zurückgerollt werden muss
• Wie stark die Kernlogik des Systems in den Köpfen weniger Leute steckt, statt dokumentiert und geteilt zu sein
• Ob es automatisierte Tests für die wichtigen Pfade gibt oder ob jedes Release von manueller Prüfung abhängt
• Wie eng die Hauptkomponenten gekoppelt sind und ob eine Änderung an der einen regelmäßig eine andere kaputt macht
• Die Historie von Incidents und Fehlern über die letzten zwei oder drei Release-Zyklen, nicht nur im aktuellen Sprint

4. Leistungsfähigkeit des Teams: Liegt es an den Leuten oder am System?

Meistens ist es kein Talentproblem. Es ist ein Problem mit Zuständigkeiten, Arbeitslast oder Entscheidungsbefugnissen, das nur wie ein Kompetenzproblem aussieht. Und genau dieser Unterschied entscheidet, ob Sie das Team behalten oder ersetzen.

Bei diesem Faktor wird die Diagnose am häufigsten verkehrt herum gestellt. Die Führung sieht ein Team, das Deadlines verpasst, und schließt daraus, dass ihm die Fähigkeiten fehlen. In vielen Fällen ist das Team aber fähig und wurde nur so aufgestellt, dass es scheitern muss: Es ist unklar, welche Teile des Systems wem gehören. Zu viel Arbeit läuft unkontrolliert parallel, sodass jeder Entwickler an sechs Dingen gleichzeitig halb fertig ist. Die Anforderungen waren nie präzise genug, um danach zu bauen. Oder der Eskalationsweg ist so lang, dass jede schwierige Entscheidung wochenlang auf eine Antwort wartet.

Die Unterscheidung ist wichtig, weil die Lösung je nach Ursache eine völlig andere ist. Eine Kompetenzlücke schließen Sie, indem Sie ändern, wer die Arbeit macht. Eine Lücke im System schließen Sie, indem Sie ändern, wie Entscheidungen fallen und wer wofür zuständig ist. Tauschen Sie dann zusätzlich das Team aus, wird es meist schlimmer, denn das neue Team erbt dieselbe kaputte Entscheidungsstruktur, in der schon das alte untergegangen ist.

• Gibt es für eine anstehende technische Entscheidung eine benannte Person, die sie treffen kann, oder wartet sie auf ein Meeting?
• Hat das Team die Fähigkeiten, die der aktuelle Stack tatsächlich verlangt, oder ist der Stack über die ursprünglich eingestellten Leute hinausgewachsen?
• War die Fluktuation ungewöhnlich hoch, vor allem bei Senior-Leuten, und begann sie, bevor oder nachdem die Lieferung langsamer wurde?
• Ist das Team auf so viele parallele Vorhaben verteilt, dass es sich nicht auf das scheiternde konzentrieren kann?
• Spricht das Team Probleme früh an, wenn etwas schiefläuft, oder kommen schlechte Nachrichten spät, weil es riskant war, sie zu melden?

5. Dienstleisterrisiko: Welchen Risiken setzt Sie der Vertrag tatsächlich aus?

Die kommerziellen Bedingungen der Zusammenarbeit (wie der Dienstleister bezahlt wird, wem der Code und die Zugänge zur Infrastruktur gehören, wie stark kritisches Wissen bei Leuten liegt, die nicht bei Ihnen angestellt sind) erklären ein festgefahrenes Projekt oft besser als jede Zeile Code. Und die meisten Führungsteams prüfen sie nie formal, solange das Projekt nicht schon in Schwierigkeiten steckt.

Eine Zusammenarbeit, die bei Vertragsabschluss vernünftig aussah, kann achtzehn Monate später zum eigentlichen Engpass werden, und die Belege dafür stehen meist im Vertrag selbst. Bei Abrechnung nach Aufwand verdient der Dienstleister gleich viel, ob das Projekt pünktlich live geht oder ein weiteres Quartal vor sich hin treibt. Die falschen Anreize sind strukturell bedingt und kein Charakterfehler der beteiligten Personen. Klauseln zum geistigen Eigentum, Regelungen zur Hinterlegung des Quellcodes und die Frage, wer tatsächlich die Zugangsdaten für Produktion und Cloud besitzt, bestimmen, wie schwer ein Wechsel wäre, falls er nötig wird. Und gebündeltes Wissen (ein oder zwei Leute, die das System verstehen und für den Dienstleister arbeiten, nicht für Sie) ist ein Risiko, das mit jedem Monat der Zusammenarbeit größer wird. Denn diese Abhängigkeit war nie dafür angelegt, aufgelöst zu werden, sondern nur dafür, erhalten zu bleiben.

Nichts davon setzt böse Absicht voraus. Wenn Dienstleister zu wenig liefern, ist das meist kein Betrug, sondern die Folge falscher Anreize, die genau so wirken, wie der Vertrag sie angelegt hat. Die Lösung beginnt damit, den Vertrag zu lesen, als wären Sie ein Außenstehender, der ihn nüchtern prüft, und nicht der Kunde, der ihn ausgehandelt hat.

• Wie wird abgerechnet, und belohnt das Abrechnungsmodell Tempo oder Dauer?
• Wem gehören heute, auf dem Papier, der Quellcode, die Infrastruktur-Accounts und die Zugangsdaten für das Deployment?
• Was würde ein Wechsel tatsächlich erfordern? Gibt es eine Ausstiegsklausel, eine Escrow-Vereinbarung, einen festgelegten Übergabeprozess oder nichts davon?
• Wie viele Menschen außerhalb Ihres Unternehmens könnten erklären, wie das System tatsächlich funktioniert, und ist diese Zahl eins?
• Waren die Berichte des Dienstleisters in sich stimmig, oder haben sich die Erklärungen für Verzögerungen bei jeder Nachfrage geändert?

6. Time to Market: Was kostet weiterer Verzug ab heute?

Entscheidend ist nicht, wie weit das Projekt schon im Verzug ist, sondern was weiterer Verzug ab jetzt kostet, verglichen mit den Kosten eines Stopps oder Neustarts. Diese Zahlen weichen oft deutlich von denen ab, die im Raum für emotionale Dringlichkeit sorgen.

Ein Projekt, das ein Jahr im Verzug ist, muss nicht automatisch aufgegeben werden. Und ein Projekt, das nur drei Monate hinterherhinkt, ist nicht automatisch rettenswert. Entscheidend ist der Verlauf der Kostenkurve ab heute. Manche Verzögerungen sind linear: Jeder weitere Monat kostet ungefähr gleich viel an verlorener Effizienz oder entgangenen Chancen. Andere sind eine Klippe: ein Stichtag für Vertragsstrafen, ein Meilenstein in der Finanzierung, eine regulatorische Frist oder der Produktstart eines Wettbewerbers, der an einem bestimmten Tag aus „spät“ „irrelevant“ macht. Wer beides verwechselt, macht einen von zwei Fehlern: Er rettet ein Projekt über den Punkt hinaus, an dem die Fertigstellung noch zählt, oder er gibt ein Projekt auf, das nie wirklich gegen eine Frist gelaufen ist.

• Gibt es ein bestimmtes Datum, nach dem das gelieferte Produkt den Großteil seines Werts oder seinen ganzen Wert verliert: eine Vertragsklausel, einen Finanzierungsmeilenstein, eine regulatorische Vorgabe, ein saisonales Marktfenster?
• Hat ein Wettbewerber die Chance, für die dieses Projekt gebaut wurde, schon genutzt, oder ist der Markt noch offen?
• Was kostet es, ein weiteres Quartal ohne diese Funktion zu arbeiten, gemessen in Zahlen und nicht in Frust?
• Wäre ein Neustart mit anderem Umfang oder anderem Team, mit allem, was Sie inzwischen wissen, tatsächlich schneller, als den aktuellen Weg weiterzugehen?

Aus sechs Faktoren wird eine von vier Entscheidungen

Kein einzelner Faktor entscheidet allein über das Ergebnis. Und es gibt keine Formel, die sechs qualitative Signale auf eine Punktzahl reduziert, ohne genau das Urteilsvermögen zu verlieren, das die Bewertung überhaupt wertvoll macht. Sobald aber alle sechs anhand von Belegen statt Annahmen bewertet sind, zeigen sich klare Muster, und sie führen zu vier Ergebnissen.

Hoher Geschäftswert, eine Codebasis, die sich sicher testen und ändern lässt, und ein Problem mit Team oder Dienstleister, das sich ohne Neuanfang beheben lässt: Dieses Muster spricht für Retten und Stabilisieren. Das heißt direkte Verantwortung für den kritischen Pfad, ein Umfang, der auf das tatsächlich Machbare zurückgesetzt wird, und ein kurzer Sanierungsplan, gemessen in Wochen, statt einer weiteren kompletten Neuplanung. Diesen Fall meinen die meisten, wenn sie vom Turnaround eines Softwareprojekts sprechen: Die Grundlagen stimmen, gefehlt haben klare Verantwortung und ein realistischer Plan, kein anderes Projekt.

Hoher Geschäftswert, aber eine Architektur, die den verbleibenden Umfang wirklich nicht tragen kann, bei einem fähigen Team und einer funktionierenden Zusammenarbeit mit dem Dienstleister: Das spricht für einen teilweisen Neubau. Was funktioniert, bleibt. Neu gebaut werden die Teile, die strukturell nicht solide sind. So wird weder das ganze System verworfen, noch ein Fundament geflickt, das nicht halten kann.

Hoher Geschäftswert und eine rettbare Architektur, aber ein Team oder Dienstleister, der nachweislich der eigentliche Engpass ist (falsche Anreize, Wissen in den falschen Händen oder dauerhaft unzuverlässige Berichte): Das spricht dafür, den Dienstleister oder das Team zu ersetzen und dabei die technische und fachliche Arbeit zu erhalten, die wirklich brauchbar ist.

Und wenn schon der Geschäftswert den oben beschriebenen nüchternen Finanzierungstest nicht besteht, spielen die anderen fünf Faktoren keine Rolle. Dann heißt das Ergebnis kontrollierter Stopp. Diese Empfehlung auszusprechen ist am schwersten. Wenn die Belege sie stützen, schützt sie aber den meisten Wert für die Zukunft, weil sie Budget freimacht, das sonst in ein Projekt fließen würde, das die Zahlen längst beerdigt haben.

Was eine unabhängige Bewertung tatsächlich liefert

Bittet man ein internes Team, das eigene Projekt nach diesen sechs Faktoren zu bewerten, liefert es bei bester Absicht eine Antwort, die von den oben beschriebenen Anreizen geprägt ist. Nicht, weil interne Teams unehrlich wären, sondern weil eine unvoreingenommene Selbstbewertung aus dem Projekt heraus strukturell kaum möglich ist.

Eine sauber abgegrenzte Bewertung beginnt nicht mit einer Lösung, sondern mit Belegen: einer unabhängigen Prüfung von Codebasis und Architektur, der bisherigen Lieferhistorie, der Restarbeit im Vergleich zu dem, was behauptet wurde, und der Team- oder Dienstleisterstruktur hinter dem Projekt. Sie liefert vier konkrete Ergebnisse: eine Risikokarte, die jedes offene technische Risiko nach geschäftlicher Auswirkung ordnet; eine Einschätzung des Fertigstellungsgrads, die die Prozentzahl durch vorführbare Meilensteine und eine ehrliche Spanne für die Restarbeit ersetzt; eine Empfehlung, die eines der vier oben genannten Ergebnisse benennt; und, wo eine Rettung sinnvoll ist, einen 30-Tage-Aktionsplan mit Scope-Freeze, technischer Sanierung, neu geordneten Zuständigkeiten und dem Governance-Rhythmus, der künftig die informellen Statusberichte ersetzt.

Ein Project Rescue Assessment mit festem Umfang über fünf Werktage kostet nur einen kleinen Bruchteil eines weiteren Quartals, in dem Sie einen Plan finanzieren, den dieselben Leute aufgestellt haben, von denen die aktuellen Statusberichte stammen. Und es ist der einzige Weg zu einer Empfehlung von jemandem, der nichts davon hat, wenn die Antwort „Weitermachen“ lautet.

Wie das mit echten Zahlen aussieht

Was es bringt, dieses Modell mit Belegen durchzugehen, zeigt sich, sobald jemand wirklich hinsieht. In einem Projekt ergab eine unabhängige Prüfung des Lieferprozesses eines B2B-SaaS-Anbieters (aktive Entwicklung, laufende Releases, eine langjährige Produktbeziehung), dass kritische Bugs, Releases in Einzelteilen und Arbeit ohne Bezug zu einem Geschäftsziel unbemerkt kommerziellen Wert vernichteten. In Zahlen gefasst lag der geschätzte Umsatzverlust durch Lieferprobleme bei 50.000 bis 220.000 $ pro Monat, die weiter gefasste mögliche Auswirkung wurde auf rund 315.000 $ pro Monat modelliert. Nichts davon war in den bestehenden Statusberichten zu sehen. Es kam erst ans Licht, als die sechs Fragen oben mit Belegen beantwortet wurden.

Ein anderes Projekt zeigt dasselbe von der Seite des Dienstleisters und der Architektur. Ein deutscher Vermittler von Fördermitteln mit einem schlanken Team von 24 Personen hatte einen einzigen systemischen Engpass: Für acht miteinander verbundene Systeme gab es keine getestete Wiederherstellungsebene, und alle hingen an einer einzigen WordPress-Datenbank als Single Source of Truth. Eine modellierte Prüfung ergab ein jährliches Risiko von 508.000 bis 1,05 Mio. EUR, das bis dahin nie beziffert und praktisch unsichtbar war. Die Wiederherstellungszeit wurde auf unter vier Stunden ausgelegt, ausgehend von einem Stand ganz ohne getesteten Restore-Prozess. Wirklich große Risiken bleiben für die Menschen, die am nächsten am Projekt sind, regelmäßig unsichtbar, gerade weil niemand Unabhängiges danach gesucht hat.

Bevor Sie mehr Budget freigeben: Was Sie zuerst prüfen sollten

Aus den sechs Faktoren ergibt sich eine kurze Liste von Schritten, die die Führung unternehmen kann, bevor ein weiterer Dollar in ein Projekt mit fraglichem Status fließt. Wenn Sie Anbieter für die Rettung von Softwareprojekten vergleichen: Ein seriöser Anbieter sollte bereit sein, genau diese sechs Faktoren mit Ihnen durchzugehen, bevor er ein Angebot für die Lösung macht, nicht erst danach.

• Verlangen Sie eine Live-Demo dessen, was das Produkt heute tatsächlich kann, keine Folien darüber, was es einmal können soll.
• Lassen Sie sich die Liste der offenen Fehler nach Schweregrad sortiert geben und fragen Sie, wie lange die kritischen Einträge schon offen sind.
• Fragen Sie, wer genau den aktuellen Build morgen in Produktion bringen könnte und was ausfiele, wenn diese Person nicht verfügbar wäre.
• Holen Sie den Vertrag mit dem Dienstleister hervor und lesen Sie Abrechnungsmodell, Klausel zum geistigen Eigentum und Ausstiegsbedingungen, als sähen Sie sie zum ersten Mal.
• Rechnen Sie den ursprünglichen Business Case mit den heutigen Zahlen neu durch (heutige Kosten bis zur Fertigstellung, heutige Marktlage) und fragen Sie sich, ob Sie ihn nüchtern betrachtet finanzieren würden.
• Klären Sie, ob es eine harte Deadline gibt, wann sie fällig ist und was genau passiert, wenn sie ohne Lieferung verstreicht.

Wenn bei mehr als einem dieser Punkte niemand eine sichere Antwort geben kann, ist schon das ein Signal: Die Entscheidung sollte nicht innerhalb der aktuellen Berichtskette fallen. Eine strukturierte, unabhängige Bewertung ist genau dafür da, diese sechs Fragen mit Belegen zu beantworten und eine von vier klaren Empfehlungen zu geben: retten und stabilisieren, teilweise neu bauen, ersetzen oder kontrolliert stoppen. Und zwar bevor das Projekt ein weiteres Quartal Budget für den Plan verbraucht, aus dem die Statusberichte stammen, die Sie gerade lesen.

Das Schwierigste an dieser Entscheidung ist nicht technisch. Es ist die Bereitschaft, sich von einem Berater ohne finanzielles Interesse am Weiterlaufen des Projekts „Stopp“ sagen zu lassen. Ein Rettungsauftrag, der immer nur zur Rettung rät, liefert Ihnen keine Diagnose, sondern ein Verkaufsgespräch mit angehängter Bewertung. Der Wert eines unabhängigen Blicks liegt gerade darin, dass er offen sagt, wenn die Belege es zeigen: Dieses Projekt sollte nicht weiterlaufen. Und zwar bevor Sie die nächste Budgetrunde freigegeben haben, um es auf die harte Tour herauszufinden.