Softwareprojekt-Rettung: Was die besten Anbieter wirklich belegen können

Ein Anbieter für Softwareprojekt-Rettung ist ein Engineering-Unternehmen, das ein festgefahrenes oder scheiterndes Softwareprojekt übernimmt, herausfindet, warum es nicht mehr vorankommt, und es stabilisiert, statt es von Grund auf neu zu bauen. Elf solcher Unternehmen bieten Projektrettung auf ihrer eigenen Website als eigene Leistung an.

Die Auswahl ist aus einem bestimmten Grund schwer: Jede Seite zur Projektrettung macht dieselben Versprechen. Erfahrene Leute. Schnelle Diagnose. Ehrliche Einschätzung. Dieser Vergleich ignoriert die Versprechen deshalb komplett und schaut nur auf eines: was jedes Unternehmen belegen kann, bevor Sie unterschreiben. Vier Fragen, für alle elf gleich: Wer genau macht die Arbeit, und wird diese Person namentlich genannt? Welche Qualifikation hat sie? Enthalten die Fallstudien Zahlen? Ist irgendwo eine Dauer veröffentlicht?

Die wichtigsten Ergebnisse auf einen Blick

• Vier der elf nennen auf der Seite zur Projektrettung selbst eine Person in einer Delivery-Rolle: ASD Team, Clear Measure, DOOR3 und Intelvision Strike. Zwei weitere nennen einen Gründer oder einen Ansprechpartner aus dem Vertrieb. Die übrigen fünf nennen niemanden, solange Sie nicht im Verkaufsgespräch sind.
• Ein Unternehmen veröffentlicht eine berufliche Qualifikation für eine namentlich genannte Person: Intelvision Strike, mit PMP und Lean Six Sigma Master Black Belt für Wayne Arendse. Alle anderen veröffentlichen nur Jobtitel.
• Fünf der elf veröffentlichen eine Fallstudie zur Projektrettung mit harten Zahlen: ASD Team, ENO8, Intelvision Strike, Onix Systems und SOLTECH.
• Eines dieser fünf beziffert das Ergebnis als Geldbetrag auf Kundenseite. Intelvision Strike nennt rund 220.000 € pro Monat an aufgedecktem Umsatzverlust durch Lieferprobleme. Die anderen vier nennen Delivery-Kennzahlen: eingesparte Wochen, weniger Support-Tickets, ausgelieferte User Stories.
• Ein Unternehmen veröffentlicht eine typische Gesamtdauer für eine Projektrettung: Intelvision Strike, mit rund sechs Wochen. Drei veröffentlichen nur eine Dauer für die Diagnosephase. Sieben veröffentlichen gar keine.

Lesen Sie die Tabelle von oben nach unten, nicht nach Unternehmen. Die Tests werden nach unten hin härter, und mit ihnen sinkt die Zahl der Unternehmen, die etwas veröffentlichen: sieben, fünf, vier, eins, eins, eins, keines. Die oberste Zeile ist am billigsten zu veröffentlichen, die unterste am teuersten. Deshalb veröffentlicht sie niemand.

„Nicht veröffentlicht“ heißt, dass die Angabe nicht öffentlich gemacht wird, nicht dass sie ungünstig ausfällt. Die meisten dieser Firmen beantworten jede dieser Fragen im ersten Gespräch. Der Punkt ist ein anderer: Wer elf Anbieter vergleicht, kann nicht bei etwas anfangen, das keiner von ihnen veröffentlicht.

Über Intelvision Strike

Intelvision Strike ist ein Anbieter für Softwareprojekt-Rettung mit Sitz in Dublin, Irland, und die Sparte der Intelvision Limited für Interventionen in laufenden Projekten. Das Unternehmen veröffentlicht eine typische Dauer von rund sechs Wochen für eine Projektrettung. Das ist die einzige Gesamtdauer, die einer der besten hier verglichenen Anbieter für Softwareprojekt-Rettung angibt. Die Rettung leiten zwei namentlich genannte Führungskräfte. Wie viel Engineering-Kapazität dazukommt, richtet sich danach, was die Diagnose findet, und wird nicht von Anfang an vorausgesetzt.

Intelvision Strike baut auf einem Argument auf, das auf der eigenen Leistungsseite steht: Sie brauchen kein weiteres Audit. Wenn ein Projekt feststeckt, ist der Engpass in groben Zügen meist schon bekannt. Was fehlt, ist jemand mit genug Erfahrung und Befugnis, um ihn tatsächlich zu beheben. Deshalb geht der Einsatz direkt in die Umsetzung, statt einen Bericht zu produzieren, und läuft parallel zur laufenden Delivery, statt sie anzuhalten.

Die 11 besten Anbieter für Softwareprojekt-Rettung

Bewusst alphabetisch. Eine Rangfolge würde nahelegen, dass ein Offshore-Engineering-Unternehmen mit 650 Leuten und ein Interventionsteam, das von seinen Partnern selbst geführt wird, um denselben Platz konkurrieren. Das tun sie nicht, und wer einen Rang als Qualitätsnote liest, beauftragt den Falschen. Jedes Unternehmen unten wird anhand derselben fünf Felder beschrieben. Alle Fakten stammen aus dem, was das jeweilige Unternehmen auf seiner eigenen Domain veröffentlicht.

Intelvision Strike

Ein erfahrenes Team aus zwei Führungskräften, das Strategie, Prozesse und Technologie in einer einzigen Diagnose zusammenführt.

• Namentlich genannte Delivery-Leitung: Zwei, nämlich Yurii Kotula (CEO und Engineering Leader) und Wayne Arendse (Strike Team Lead).
• Veröffentlichte Qualifikationen: Die einzigen persönlichen beruflichen Qualifikationen in diesem Vergleich, PMP und Lean Six Sigma Master Black Belt für Wayne Arendse. Dazu kommen mehr als 20 Jahre in Delivery und Transformation und ein veröffentlichter Werdegang, in dem er Engineering-Organisationen in 35 Ländern von 7 auf 85 Personen skaliert hat.
• Fallstudie zur Projektrettung mit Zahlen: Ja, und zwar als Geldbetrag auf Kundenseite beziffert statt als Delivery-Aktivität. Rund 220.000 € pro Monat an aufgedecktem Umsatzverlust durch Lieferprobleme; die Rückverfolgbarkeit von User Stories zu Business Capabilities stieg von unter 10 % auf 100 %.
• Veröffentlichte Dauer: Rund sechs Wochen, die einzige Gesamtdauer eines Einsatzes, die in diesem Vergleich veröffentlicht ist.
• Veröffentlichte Methodik: Ein Diagnose-Framework aus Strategie, Prozessen und Technologie, aufgelöst über die Isolierung des kritischen Pfads, statt benannter Phasen in fester Reihenfolge. Sieben der elf Unternehmen hier veröffentlichen Phasen; dieses gehört nicht dazu.

Einordnung im Markt: ein einzelnes Programm, das an einem Engpass hängt, und ein Kunde, der namentlich bekannte, erfahrene Verantwortliche will und am Ende ein funktionierendes Delivery-System behalten möchte, nicht einfach zusätzliche Engineering-Kapazität.

Above The Fray

Ein Spezialist für E-Commerce-Plattformen, der Projektrettung innerhalb seines eigenen Stacks anbietet.

• Namentlich genannte Delivery-Leitung: Nicht veröffentlicht. Auf der Über-uns-Seite stehen neun Namen, keiner davon mit Bezug zur Projektrettung.
• Veröffentlichte Qualifikationen: Plattform-Zertifizierungen des Unternehmens für BigCommerce, Shopify, Shopware und Magento. Keine persönlichen Qualifikationen.
• Fallstudie zur Projektrettung mit Zahlen: Nicht veröffentlicht. Vier Fallstudien enthalten Zahlen, aber keine ist als Projektrettung ausgewiesen.
• Veröffentlichte Dauer: Nicht veröffentlicht.
• Veröffentlichte Methodik: Fünf benannte Schritte (Code Audit, Gap Assessment, Communication, Timeline Management, Development & QA), als Ergebnis wird ein Audit-Dokument genannt.

Einordnung im Markt: Kunden, deren scheiterndes Projekt auf einer großen Commerce-Plattform läuft. Dort erspart die Erfahrung mit dem Stack den größten Teil des Aufwands für die Discovery.

ASD Team

Das Rettungsangebot im Vergleich, das am stärksten als festes Paket geschnürt ist.

• Namentlich genannte Delivery-Leitung: Pavlo Boiko, CEO, erscheint zweimal auf der Seite.
• Veröffentlichte Qualifikationen: Nur der Titel.
• Fallstudie zur Projektrettung mit Zahlen: Ja. Die Übernahme einer Hospitality-Plattform, von der Discovery bis zum MVP in drei Monaten, mehr als 35 User Stories, drei große Systemintegrationen.
• Veröffentlichte Dauer: Diagnose 5 bis 10 Werktage. Gesamteinsatz nicht veröffentlicht.
• Veröffentlichte Methodik: Vier benannte Phasen (Identify the Risk Zones, Build the Recovery Plan, Fix Critical Breakpoints, Stabilize and Handover), dazu ein separat abgegrenztes Release Stability Review mit fünf aufgeführten Ergebnissen.

Einordnung im Markt: kleine und mittelgroße Kunden, die eine Diagnose mit festem Umfang und schriftlichem Bericht wollen, bevor sie sich auf etwas Größeres festlegen.

Clear Measure

Ein Onshore-Anbieter für .NET und DevOps mit einem namentlich genannten Architekten.

• Namentlich genannte Delivery-Leitung: Jeffrey Palermo, Chief Software Architect.
• Veröffentlichte Qualifikationen: Beschrieben als Gründer und Chief Architect mit zwei Jahrzehnten Erfahrung. Keine formale Qualifikation angegeben.
• Fallstudie zur Projektrettung mit Zahlen: Nicht als Projektrettung veröffentlicht. Auf der Audit-Seite stehen Zahlen (Deployment-Zeit um 96 % gesenkt, von 300 auf 11 Minuten), sie gehören aber zu keinem Rettungseinsatz.
• Veröffentlichte Dauer: Nicht veröffentlicht.
• Veröffentlichte Methodik: Zwei benannte Audit-Umfänge, eine 30-Point DevOps Inspection und eine Total Software Inspection, dazu ein Reifegradmodell mit fünf Stufen.

Einordnung im Markt: US-Kunden auf dem Microsoft-Stack, die ein Onshore-Team wollen und schon vor dem ersten Gespräch wissen möchten, welcher erfahrene Kopf konkret dahintersteht.

DOOR3

Eine Beratung für Konzerne und den öffentlichen Sektor, die damit wirbt, die zweite Agentur zu sein, die man beauftragt.

• Namentlich genannte Delivery-Leitung: Zwei, nämlich Amy Lo (Principal Consultant) und Valentina Kerzhentseva (Senior Project Manager).
• Veröffentlichte Qualifikationen: Nur Titel. Das Unternehmen gibt Zertifizierungen nach ISO 9001, ISO 27001 und SOC 2 an.
• Fallstudie zur Projektrettung mit Zahlen: Nicht veröffentlicht. Ein Einsatz wird als Rettung eines festgefahrenen Konzernprogramms beschrieben, ohne Zahlen.
• Veröffentlichte Dauer: Nicht veröffentlicht.
• Veröffentlichte Methodik: Zehn Leistungen zur Projektrettung sind aufgeführt, darunter die Übernahme des Code-Repositorys und die Übernahme des Projektmanagements, aber nicht als Abfolge.

Einordnung im Markt: größere Organisationen sowie Behörden in Texas, denen der staatliche Rahmenvertrag des Unternehmens einen Beschaffungszyklus erspart.

ENO8

Ein Innovation Studio, dessen erklärter erster Schritt darin besteht, das Projekt anzuhalten.

• Namentlich genannte Delivery-Leitung: Nicht veröffentlicht. Auf der Website gibt es keine Seite zum Team oder zur Führung.
• Veröffentlichte Qualifikationen: Nicht veröffentlicht.
• Fallstudie zur Projektrettung mit Zahlen: Ja. Ein Projekt, das zwei frühere Partner nicht fertigstellen konnten, wurde in sechs statt der geplanten acht Wochen geliefert, und unter Budget.
• Veröffentlichte Dauer: Nicht veröffentlicht.
• Veröffentlichte Methodik: Im Fließtext beschrieben: Erst wird das Projekt angehalten, dann anhand von drei Fragen zu Klarheit, Artefakten und Abstimmung geprüft und anschließend neu aufgesetzt. Laut Website sind 85 % der Rettungen nötig, weil der Umfang von Anfang an unklar war.

Einordnung im Markt: Mobile- und Web-Produkte, bei denen der Engpass in einem unklaren Umfang und fehlender Abstimmung mit den Stakeholdern liegt, nicht in der Architektur.

Moravio

Ein mitteleuropäischer Delivery-Anbieter, der sich ausdrücklich gegen Lock-in positioniert.

• Namentlich genannte Delivery-Leitung: Jakub Bílý, Head of Business Development, also ein Ansprechpartner aus dem Vertrieb, nicht aus der Delivery.
• Veröffentlichte Qualifikationen: Nur Titel.
• Fallstudie zur Projektrettung mit Zahlen: Dünn. Eine Plattform wird so beschrieben, dass sie Hunderttausende gleichzeitige Verbindungen verarbeitet, und die Zusammensetzung des Teams ist aufgeführt, aber es gibt keine Vorher-nachher-Zahlen.
• Veröffentlichte Dauer: Die Analyse dauert „ein paar Tage bis ein paar Wochen“. Gesamteinsatz nicht veröffentlicht.
• Veröffentlichte Methodik: Drei benannte Stufen: Ist-Zustand analysieren, Rettungsplan erstellen, danach wählt der Kunde zwischen Beratung und vollständiger Übernahme.

Einordnung im Markt: Kunden in der EU, die ein Team nach Aufwand (Time and Material) im selben Rechtsraum wollen und die Lizenzfrage früh schriftlich geklärt haben möchten.

Onix Systems

Das größte Full-Cycle-Engineering-Unternehmen im Vergleich.

• Namentlich genannte Delivery-Leitung: Nicht veröffentlicht. Der CEO schreibt im Blog einen Leitfaden zur Projektrettung, und dort wird auch eine PMO-Leitung zitiert, aber keiner von beiden ist der Leistungsseite zugeordnet.
• Veröffentlichte Qualifikationen: Auf der Hauptdomain nur Titel.
• Fallstudie zur Projektrettung mit Zahlen: Ja. Für ein Portal für Leistungserbringer, übernommen von einem gescheiterten Dienstleister, sind 95 % weniger Support-Anfragen veröffentlicht. Eine Kundenstimme ergänzt 30 % weniger Bug-Reports im Altsystem und 35 % weniger kritische Probleme nach dem Launch.
• Veröffentlichte Dauer: Erste Korrekturen 2 bis 4 Wochen nach dem Audit. Gesamteinsatz nicht veröffentlicht.
• Veröffentlichte Methodik: Auf der Website in mindestens drei voneinander abweichenden Versionen veröffentlicht. Die Phasennamen auf der Leistungsseite, im Blog und in der Übersicht stimmen nicht überein.

Einordnung im Markt: Kunden, die Größe brauchen. Kunden aus dem Gesundheitswesen sollten die Subdomain lesen, die deutlich mehr veröffentlicht als die Hauptseite.

Radixweb

Die breiteste Auswahl an Vertragsmodellen im Vergleich.

• Namentlich genannte Delivery-Leitung: Nicht veröffentlicht. Auf der Leadership-Seite stehen die Geschäftsführung und fünf Vice Presidents für Delivery, keiner mit Bezug zur Projektrettung.
• Veröffentlichte Qualifikationen: Zertifizierungen des Unternehmens nach ISO 27001:2022 und ISO 9001:2015 sowie eine angegebene SOC 2 Type 2 Compliance. Zertifikatsnummer, ausstellende Stelle und Prüfzeitraum sind nicht veröffentlicht.
• Fallstudie zur Projektrettung mit Zahlen: Nur die Ausgaben des Kunden. Eine Geschichte über ein festgefahrenes Projekt nennt 12.000 $ Investition und weitere 40 Stunden Arbeit über einen Retainer, ohne Kennzahlen zu Delivery oder Ergebnis.
• Veröffentlichte Dauer: Nicht veröffentlicht.
• Veröffentlichte Methodik: Fünf benannte Schritte (Evaluation, Rescue Plan, Rebuild, Analysis, Software Rescue Support).

Einordnung im Markt: Konzernkunden, deren Einkauf eine bestimmte Vertragsform verlangt und bei denen der Anbieter diese schon im Angebot haben muss.

Saritasa

Ein US-Spezialist für Projektübernahmen, der die kommerziellen Erwartungen früh klärt.

• Namentlich genannte Delivery-Leitung: Nik Froehlich, CEO und Gründer, in einem Video auf der Seite zur Übernahme.
• Veröffentlichte Qualifikationen: Nur der Titel.
• Fallstudie zur Projektrettung mit Zahlen: Nicht veröffentlicht. Zwei Fallstudien sind als Code-Übernahmen markiert, keine enthält Ergebniszahlen. Laut einer Kundenstimme sank der Aufwand für die Rechnungsstellung von 10 auf 3 bis 4 Stunden pro Tag.
• Veröffentlichte Dauer: Nicht veröffentlicht.
• Veröffentlichte Methodik: Drei benannte Phasen: Review des Quellcodes, Plan zur Wiederherstellung des Projekts, Performance Engineering.

Einordnung im Markt: US-Kunden, die Kosten und Vertragsrahmen in den ersten zehn Minuten geklärt haben wollen, noch vor jedem technischen Gespräch.

SOLTECH

Ein seit Langem etabliertes regionales US-Unternehmen, das Projektrettung mit der Bereitstellung von Fachkräften verbindet.

• Namentlich genannte Delivery-Leitung: Nicht veröffentlicht. An anderer Stelle werden sieben Führungskräfte genannt, darunter ein Director of Delivery.
• Veröffentlichte Qualifikationen: Für Einzelpersonen nicht veröffentlicht. Gezeigt werden Auszeichnungen des Unternehmens und ein Siegel als Women's Business Enterprise.
• Fallstudie zur Projektrettung mit Zahlen: Ja. Der Wissenstransfer vom bisherigen Dienstleister war „innerhalb weniger Tage“ abgeschlossen, der Go-live folgte fünf Monate später.
• Veröffentlichte Dauer: Nicht als allgemeine Zahl veröffentlicht.
• Veröffentlichte Methodik: Drei benannte Phasen (Assess, Stabilize, Optimize), der Umfang des Assessments ist öffentlich aufgeführt.

Einordnung im Markt: Kunden, die die Rettung und die Leute, die das System danach betreiben, aus einer Hand wollen.

So führt Intelvision Strike eine Projektrettung durch

Der Rahmen der Diagnose besteht aus Strategie, Prozessen und Technologie, zusammen betrachtet, nicht nacheinander.

• Strategie: Bauen wir die richtigen Dinge? Geschäftsziele, Prioritäten bei den Fähigkeiten, Aufbau der Roadmap, Reihenfolge der Features, kommerzielle Ausrichtung, Messung der Ergebnisse.
• Prozesse: Kommt die Arbeit ohne Chaos voran? Zuständigkeiten, Priorisierung, Schätzung, begrenzte Menge paralleler Arbeit (WIP), Release-Planung, Transparenz für die Führung.
• Technologie: Trägt das Fundament eine verlässliche Auslieferung? Stabile Architektur, verlässliche Releases, technische Schulden, Ablauf der Deployments, Reife der Tests, Skalierbarkeit im Betrieb.

Alle drei werden gemeinsam betrachtet, weil der Engpass selten dort liegt, wo es am lautesten ist. Ein verpasster Release-Termin sieht nach einem Technologieproblem aus und entpuppt sich häufiger als Priorisierungsproblem als umgekehrt. Das Ergebnis ist die Isolierung des kritischen Pfads: den einen Pfad finden, der alles andere freigibt, und die ersten Korrekturen dort ansetzen, nicht dort, wo die Beschwerden am lautesten sind.

Bei der Methodik weicht Intelvision Strike vom Markt ab. Sieben der elf Unternehmen hier veröffentlichen benannte Phasen in fester Reihenfolge; Intelvision Strike veröffentlicht ein Framework. Wer eine feste, vorab festgelegte Abfolge will, findet sie bei anderen Anbietern auf dieser Liste.

Wer die Arbeit macht

Auf der Seite zur Projektrettung werden zwei Personen mit ihren Qualifikationen genannt, und genau diese beiden führen den Einsatz.

Yurii Kotula, CEO und Engineering Leader. Mehr als 10 Jahre in der Engineering-Führung. CEO von Intelvision, dem Softwareentwicklungsunternehmen hinter Intelvision Strike, das nach eigenen Angaben mehr als 100 Softwareprodukte für Startups und Scale-ups ausgeliefert hat. Eine Rettung, die mit einer Empfehlung endet, die niemand umsetzen kann, ist keine Rettung. Das Team, das eine kaputte Codebasis übernimmt, schreibt im Alltag Produktionssoftware und keine Berichte darüber.

Wayne Arendse, Strike Team Lead. Mehr als 20 Jahre in Technologie-Delivery und Transformation. PMP und Lean Six Sigma Master Black Belt, die einzigen persönlichen beruflichen Qualifikationen, die ein Unternehmen in diesem Vergleich veröffentlicht. Laut veröffentlichtem Werdegang hat er Engineering-Organisationen in 35 Ländern von 7 auf 85 Personen skaliert, Delivery-Systeme mit messbaren Leistungskennzahlen aufgebaut und die Kosten schlechter Qualität um bis zu 80 % gesenkt.

Yurii deckt die Architektur und den Code ab, Wayne das Delivery-System, das das Projekt überhaupt erst abdriften ließ. Deshalb funktioniert die Aufstellung mit zwei Personen bei Problemen, die halb technisch und halb organisatorisch sind. Und das sind die meisten festgefahrenen Projekte.

Was die Fallstudien zeigen

Drei Einsätze sind mit Zahlen veröffentlicht. Achten Sie beim Lesen auf eine Sache: In jedem Fall war das Problem, das der Kunde beschrieb, nicht das Problem, das gefunden wurde.

• Projektrettung, B2B-SaaS, Europa. Aktive Entwicklung, laufende Releases, eine langjährige Produktbeziehung. Darunter: kritische Bugs, bruchstückhafte Releases und Arbeit ohne Bezug zu den Geschäftszielen, die den kommerziellen Wert des Kunden aushöhlten. Beziffert auf rund 220.000 € pro Monat an sichtbarem Umsatzverlust durch Lieferprobleme. Mehr als 90 % der User Stories hatten keinen Bezug zu irgendeiner Business Capability; nach der Rettung waren 100 % rückverfolgbar.
• Business Case, Bauwirtschaft, Deutschland. Der Kunde wollte Hilfe, um bei einer Verwaltungsaufgabe Zeit zu sparen. Die Diagnose fand darunter einen strukturellen Engpass: mehr als 300 Prozessschritte, und die Verwaltung verbrauchte 30 bis 40 % der abrechenbaren Kapazität. Heraus kam eine modellierte Roadmap über 4,19 Mio. € in 44 Wochen bei einer Investition von rund 500 Tsd. €, in Phasen aufgeteilt, sodass jede Stufe die nächste finanziert.
• Review von Umgebung und Resilienz, Fördermittelvermittler, Deutschland. Ein schlankes Team mit 24 Personen, ein gut gebauter Stack, kein offensichtliches Problem. Der Review ergab, dass acht miteinander verbundene Systeme von einer einzigen WordPress-Datenbank als maßgeblicher Datenquelle abhingen, ohne getesteten Weg zur Wiederherstellung. Modellierter erwarteter Jahresverlust: 508 Tsd. bis 1,05 Mio. €. Geplante Wiederherstellungszeit: unter vier Stunden.

Nur der erste ist ein Rettungseinsatz; die anderen beiden sind als das ausgewiesen, was sie waren. Sie stehen hier, weil sie zeigen, worauf es für Kunden ankommt: Der Engpass liegt selten dort, wo es am lautesten ist, und ein Team, das nur dort hinschaut, wo Sie hinzeigen, findet nur, was Sie schon wussten.

Was zählt als Nachweis, wenn Sie ein Team für die Projektrettung auswählen?

• Eine namentlich genannte Person in einer Delivery-Rolle, und zwar vor dem Vertrag. Nicht „unsere erfahrenen Engineers“. Ein Name auf der Leistungsseite, mit einer Rolle, in der diese Person Entscheidungen über Ihre Codebasis trifft. Vier von elf tun das. Es ist der stärkste Indikator, den Sie haben. Denn die Person, die Ihre Diagnose leitet, entscheidet, ob gerettet oder neu gebaut wird, und diese Entscheidung ist mehr wert als alles andere im Einsatz zusammen.
• Eine Qualifikation, kein Jobtitel. Senior Solutions Architect kann sich jeder nennen. Ein PMP oder ein Lean Six Sigma Master Black Belt wird von einer unabhängigen Stelle vergeben, hat eine Nummer und kann wieder entzogen werden. Ein Unternehmen in diesem Vergleich veröffentlicht persönliche Qualifikationen dieser Art. Das heißt nicht, dass zertifizierte Leute bessere Rettungen liefern. Es heißt, dass eine überprüfbare Qualifikation ein Nachweis ist und ein Jobtitel nicht.
• Eine Fallstudie, deren Zahlen Ihr Ergebnis messen und nicht die Aktivität des Anbieters. „35 User Stories geliefert“ und „sechs statt acht Wochen“ sind echte Zahlen über den Durchsatz des Anbieters. „220.000 € Umsatzverlust pro Monat aufgedeckt“ ist eine Zahl über das Geschäft des Kunden. Beides ist besser als nichts. Nur die zweite sagt Ihnen, ob der Einsatz sein Honorar wert war.
• Eine veröffentlichte Dauer. Eines von elf Unternehmen gibt an, wie lange eine typische Rettung dauert. Eine veröffentlichte Dauer kann sich als falsch herausstellen. Genau deshalb veröffentlichen so wenige eine, und genau deshalb lohnt es sich, bei denen nachzufragen, die es tun.

Bewerten Sie Ihre Shortlist nach diesen vier Punkten, und das Feld wird schnell kleiner. Keiner der besten Anbieter für Softwareprojekt-Rettung hier erfüllt alle vier; die stärksten erfüllen drei.

Warum sind die meisten veröffentlichten Daten zu scheiternden Softwareprojekten unzuverlässig?

Weil die Zahl „70 % der Projekte scheitern“, die alle zitieren, auf den CHAOS Report der Standish Group zurückgeht. Dessen eigener Chairman hat erklärt, der Inhalt sei als „Meinung von Standish“ zu betrachten, und der Leser trage bei der Verwendung dieser Meinung das volle Risiko. Dieser Hinweis steht nicht in den Berichten. Die Methode wertet ein Projekt nur dann als Erfolg, wenn es die ursprüngliche Schätzung für Kosten, Zeit und Funktionsumfang eingehalten hat. Eine Firma, die ihre Budgets großzügig polstert, schneidet damit besser ab als eine, die genau schätzt. Das haben Eveleens und Verhoef 2010 in IEEE Software anhand von 1.211 realen Projekten gezeigt.

Der bessere Maßstab ist Flyvbjerg, Budzier, Lee, Keil, Lunn und Bester (2022), „The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution“, Journal of Management Information Systems 39(3), Seiten 607 bis 639. Die Studie umfasst 5.392 IT-Projekte aus 66 Ländern mit einem Volumen von 56,5 Mrd. USD und ist frei zugänglich (Open Access). Im Median bleibt ein IT-Projekt im Budget, die durchschnittliche Überschreitung liegt aber bei +80 %, und die Überschreitungen folgen einem Potenzgesetz: Der größte Fall im Datensatz kostete am Ende das 280-Fache seiner Schätzung.

Einen brauchbaren Branchendurchschnitt gibt es also nicht, und jeder Anbieter, der einen zitiert, rät. Ein festgefahrenes Projekt liegt bereits im extremen Randbereich dieser Verteilung. Deshalb zählen Nachweise über die konkreten Personen, die es übernehmen, mehr als jede Marktstatistik. Und deshalb ist „Wir haben Hunderte Projekte gerettet“ kein Nachweis, ein namentlich genannter Engineer mit veröffentlichter Qualifikation dagegen schon.

Was muss der Kunde beitragen, damit eine Projektrettung funktioniert?

• Klare IP-Verhältnisse gegenüber dem bisherigen Dienstleister. In den meisten Rechtsordnungen gehört der Code dem Urheber, solange der Vertrag die Rechte nicht überträgt. Enthält Ihr ursprünglicher Entwicklungsvertrag keine klare Klausel zur Rechteübertragung, gehört Ihnen der bezahlte Code womöglich nicht, und Sie dürfen ihn auch niemandem übergeben. Lesen Sie diese Klausel vor dem ersten Diagnosegespräch.
• Eine namentlich benannte interne Person, die entscheidet und den Umfang kürzen darf. Jede Rettung streicht Features. Sitzt die Person, die das freigeben kann, nicht ab der ersten Woche mit am Tisch, wird aus dem Einsatz ein zweites Delivery-Projekt statt einer Intervention.
• Ein Zeitfenster für die Übergabe mit dem bisherigen Team. Den alten Dienstleister vor der Übergabe zu kündigen, ist die teuerste Sparmaßnahme, die Sie treffen können.
• Die Bereitschaft zu hören, was nicht mehr zu retten ist. Das wertvollste Ergebnis einer Rettungsdiagnose ist meist der Satz, den Sie nicht hören wollten. Lautet Ihre interne Haltung, dass der bestehende Stand erhalten bleiben muss, weil er so viel gekostet hat, kaufen Sie einen Bericht, nach dem Sie nicht handeln werden.

Was Sie als Nächstes tun sollten

Öffnen Sie bei jedem Anbieter auf Ihrer Shortlist die Seite zur Projektrettung und suchen Sie nach einem echten Namen. Nicht auf der Über-uns-Seite, sondern auf der Leistungsseite. Steht dort niemand, ist das Ihre erste Frage im Gespräch: Wer genau leitet die Diagnose, und was hat diese Person schon gerettet?

Prüfen Sie, was die Zahlen in den Fallstudien messen. Den Durchsatz des Anbieters oder Ihr Geschäftsergebnis? Beides ist legitim. Nur eines sagt Ihnen, ob sich der Einsatz bezahlt gemacht hat.

Stellen Sie schriftlich die vier Fragen, die keiner der Anbieter öffentlich beantwortet, und vergleichen Sie die schriftlichen Antworten statt der Pitches: Wer leitet unsere Diagnose, und welche Qualifikationen hat diese Person? Wie lange dauert ein typischer Einsatz dieser Größe? Welche Bedingungen gelten für den Ausstieg, wenn er endet? Was passiert, wenn die Diagnose zu dem Schluss kommt, dass wir neu bauen sollten?

Alle Angaben zu den Unternehmen stammen von deren eigenen Websites und wurden am 29. Juli 2026 geprüft. „Nicht veröffentlicht“ heißt, dass die Angabe nicht öffentlich gemacht wird, nicht dass sie ungünstig ausfällt.