IT-Projekt retten: Vorgehen, wenn das Projekt kippt

Ein IT-Projekt zu retten beginnt nicht mit mehr Ressourcen, sondern mit einer ehrlichen Bestandsaufnahme. Der typische Ablauf einer Projektkrise ist immer derselbe: Der Termin wird zweimal verschoben, dann werden zusätzliche Entwickler eingekauft, dann steigt der Druck auf alle Beteiligten – und erst danach stellt jemand die Frage, ob das Projekt in dieser Form überhaupt noch das richtige ist.

Dieser Ratgeber dreht die Reihenfolge um. Er beschreibt die Warnsignale, die Sofortmaßnahmen der ersten zehn Tage, ein Verfahren für die Entscheidung zwischen Weiterführen, Umbauen, Neustart und Abbruch, den Sanierungsplan und die rechtliche Absicherung während der Rettung. Warum Projekte überhaupt in diese Lage geraten, behandelt der Ratgeber Warum Softwareprojekte scheitern – hier geht es um den Fall, dass es bereits passiert ist.

Zwölf Warnsignale, dass Ihr IT-Projekt in der Krise steckt

Je mehr davon zutreffen, desto weniger Zeit haben Sie. Ab etwa fünf ist die Krise real, unabhängig davon, was der Statusbericht sagt.

• Der Termin wurde bereits zweimal verschoben, ohne dass sich der Umfang geändert hat.
• Statusberichte sind seit Wochen unverändert „auf gutem Weg", aber niemand kann etwas vorführen.
• Es gibt keinen lauffähigen Stand, den Sie selbst bedienen können.
• Der Anteil der Zeit für Fehlerbehebung steigt, der für neue Funktionen sinkt.
• Behobene Fehler tauchen wieder auf.
• Schlüsselpersonen auf einer der beiden Seiten wurden ausgetauscht.
• Die Kommunikation wird formeller – Anwälte werden erwähnt, E-Mails werden in Kopie an mehr Personen geschickt.
• Entscheidungen werden vertagt statt getroffen.
• Es gibt keine belastbare Antwort auf die Frage, wie viel Prozent fertig sind.
• Änderungsaufträge häufen sich, ohne dass jemand die Gesamtsumme kennt.
• Das Team arbeitet dauerhaft über die reguläre Zeit hinaus.
• Niemand spricht mehr über die ursprünglichen Projektziele.

Das aussagekräftigste Signal ist der dritte Punkt. Solange Sie ein Softwareprojekt nicht selbst anfassen können, wissen Sie nicht, wo es steht – unabhängig davon, wie detailliert der Statusbericht ist.

Die vier Krisenstufen

Stufe	Was passiert	Erkennbar an	Handlungsspielraum
1. Führungs- und Stakeholder-Krise	Konflikte oder Überforderung beeinflussen Grundsatzentscheidungen	widersprüchliche Vorgaben, wechselnde Prioritäten	groß
2. Strategiekrise	Ziele fehlen oder sind unklar geworden	„Was bauen wir hier eigentlich?"	groß
3. Meilensteinkrise	Termine reißen, Budget läuft, Qualität sinkt	Verschiebungen, Überstunden, Fehlerstau	mittel
4. Ergebniskrise	Die Ziele sind nicht mehr erreichbar	offene Frage nach Abbruch	gering

Die Stufen bauen aufeinander auf: Eine ungelöste Führungs- oder Strategiekrise schlägt auf das operative Vorgehen durch und wird dort als Meilensteinkrise sichtbar. Das erklärt, warum rein operative Rettungsversuche – mehr Leute, mehr Druck, engere Berichtstakte – regelmäßig scheitern: Sie behandeln das Symptom auf Stufe 3, während die Ursache auf Stufe 1 oder 2 liegt.

Die ersten zehn Tage: Sofortmaßnahmen

Ziel dieser Phase ist nicht, das Projekt zu reparieren, sondern es zu stabilisieren und eine belastbare Faktenlage zu schaffen.

1. Krise benennen. Solange offiziell alles im Plan ist, arbeitet niemand an der Lösung. Diesen Schritt kann nur die Auftraggeberseite gehen.
2. Neue Zusagen stoppen. Keine weiteren Änderungsaufträge, keine neuen Anforderungen, bis die Lage geklärt ist.
3. Fakten sichern. Vertrag, Leistungsbeschreibung, alle Änderungsaufträge, Protokolle, Statusberichte, Rechnungen und die bisher gezahlten Beträge an einem Ort zusammenführen – vollständig und datiert.
4. Zugriff sicherstellen. Haben Sie Zugang zum Quellcode, zu den Repositories, zur Infrastruktur, zu den Zugangsdaten? Wenn nicht, ist das der dringlichste Punkt der ganzen Liste.
5. Den tatsächlichen Stand feststellen. Nicht nach Prozentangaben fragen, sondern sich den lauffähigen Stand vorführen lassen – auf einem System, das Sie selbst bedienen können.
6. Mit dem Team sprechen, nicht nur mit der Projektleitung. Einzelgespräche mit Entwicklerinnen und Entwicklern beider Seiten liefern in zwei Tagen mehr als vier Wochen Statusberichte.
7. Externen Blick holen. Ein unabhängiges technisches Assessment kostet fünf bis fünfzehn Personentage und ist die Voraussetzung für jede weitere Entscheidung.
8. Mängel dokumentieren. Ab jetzt schriftlich, mit Datum, Beschreibung und Auswirkung – unabhängig davon, ob Sie später rechtliche Schritte erwägen.

Das Assessment: Ist das IT-Projekt noch zu retten?

Vier Fragen bestimmen die Antwort. Beantworten Sie sie getrennt, bevor Sie eine Gesamtentscheidung treffen:

1. Ist die Fachlichkeit klar? Wenn niemand präzise sagen kann, was das System leisten soll, ist kein Anbieterwechsel und kein zusätzliches Personal die Lösung. Dann muss zuerst die Anforderungsarbeit nachgeholt werden.

2. Taugt das Bestehende? Ein technisches Assessment beantwortet das: Struktur des Codes, Testabdeckung, Dokumentation, Abhängigkeiten, Sicherheit. Es liefert die Zahl, die alles Weitere bestimmt – den Anteil des Bestehenden, der weiterverwendbar ist.

3. Ist die Zusammenarbeit reparabel? Manche Krisen sind fachlich lösbar, aber zwischenmenschlich verbrannt. Ein Austausch der handelnden Personen auf einer oder beiden Seiten löst mehr, als viele erwarten.

4. Rechnet sich die Fortsetzung noch? Rechnen Sie ausschließlich mit den Kosten ab heute. Was bereits ausgegeben wurde, ist für diese Entscheidung ohne Bedeutung – es ist weg, egal wie Sie sich entscheiden. Diese Regel ist einfach zu formulieren und schwer einzuhalten; sie ist trotzdem die wichtigste.

Situation	Empfehlung
Fachlichkeit klar, Code brauchbar, Zusammenarbeit reparabel	Sanieren mit dem bestehenden Partner
Fachlichkeit klar, Code brauchbar, Zusammenarbeit zerrüttet	Anbieterwechsel mit geordneter Übergabe
Fachlichkeit klar, Code unbrauchbar	Neustart der Umsetzung, Anforderungen behalten
Fachlichkeit unklar	Entwicklung pausieren, Anforderungsarbeit nachholen
Geschäftlicher Nutzen entfallen	Abbruch – geordnet, mit Sicherung aller Ergebnisse

IT-Projekt retten: der Sanierungsplan

Wenn die Entscheidung für eine Sanierung gefallen ist, hat sich dieses Vorgehen bewährt:

• Umfang radikal kürzen. Definieren Sie den kleinsten Stand, der produktiv gehen kann, und streichen Sie alles andere in eine spätere Ausbaustufe. Ein Projekt in der Krise gewinnt nicht durch Vollständigkeit, sondern durch einen Erfolg.
• Einen nahen, echten Meilenstein setzen. Vier bis sechs Wochen, mit einem Ergebnis, das jemand tatsächlich benutzt. Nichts stabilisiert ein Projekt so verlässlich wie ein eingehaltener Termin.
• Entscheidungswege verkürzen. Eine benannte Person auf jeder Seite mit Entscheidungsbefugnis und Zeit. Gremien verlängern Krisen.
• In kurzen Zyklen liefern. Alle ein bis zwei Wochen ein lauffähiger Stand zum Anfassen. Das ersetzt Statusberichte durch Tatsachen.
• Qualität messbar machen. Zahl offener Fehler, Testabdeckung, Zeit von der Änderung bis zur Auslieferung. Drei Kennzahlen genügen, wöchentlich erhoben.
• Erst stabilisieren, dann Ursachen beheben. Solange das Projekt brennt, ist keine Zeit für Strukturarbeit. Die Ursachenanalyse folgt, wenn der erste Meilenstein steht.
• Nicht auf Verdacht aufstocken. Zusätzliches Personal in einem verzögerten Projekt bindet zunächst Kapazität für Einarbeitung und verschärft die Lage kurzfristig.

Rechtliche Absicherung während der Rettung

Dieser Abschnitt ist eine erste Orientierung und ersetzt keine Rechtsberatung. Bei einem gescheiterten Projekt mit erheblichem Volumen ist anwaltliche Begleitung ab dem Zeitpunkt sinnvoll, an dem eine Kündigung im Raum steht.

Auch wenn Sie das Projekt retten wollen, sollten Sie Ihre Position sichern – die Maßnahmen widersprechen einander nicht:

• Mängel schriftlich rügen, mit Datum, konkreter Beschreibung und Auswirkung. Sammeln Sie diese Meldungen an einem Ort.
• Angemessene Fristen zur Nacherfüllung setzen, ebenfalls schriftlich. Das ist regelmäßig Voraussetzung für weitergehende Rechte.
• Vertragstyp klären. Beim Werkvertrag schuldet der Auftragnehmer einen Erfolg, es gibt eine Abnahme; beim Dienstvertrag lediglich fachgerechtes Tätigwerden. Davon hängt ab, was Sie überhaupt verlangen können – siehe Werkvertrag oder Dienstvertrag?
• Kündigungsmöglichkeiten kennen. Beim Werkvertrag kann der Besteller nach deutschem Recht bis zur Fertigstellung kündigen; der Unternehmer behält dann grundsätzlich den Vergütungsanspruch abzüglich ersparter Aufwendungen. Ein Ausstieg ist also möglich, aber selten kostenlos.
• Warnpflichten prüfen. Wusste der Auftragnehmer, dass Vorgaben oder Grundlagen untauglich waren, und hat er darauf hingewiesen? In Österreich ist diese Warnpflicht in § 1168a ABGB ausdrücklich geregelt und kann die Haftungsverteilung erheblich verschieben.
• Zugriff sichern. Quellcode, Dokumentation, Zugangsdaten, Infrastrukturkonten. Wenn diese Punkte im Vertrag nicht geregelt sind, verhandeln Sie sie jetzt – nicht erst bei der Kündigung.
• Zahlungen an Ergebnisse koppeln. Offene Rechnungen sind Ihr wirksamstes Verhandlungsmittel. Zahlungen ohne Gegenleistung einzustellen, sollte allerdings rechtlich geprüft sein.

Wann Abbruch die richtige Entscheidung ist

Der Abbruch ist kein Scheitern, sondern eine wirtschaftliche Entscheidung. Er ist richtig, wenn der geschäftliche Nutzen entfallen ist, wenn die verbleibenden Kosten den erwarteten Nutzen übersteigen, wenn die Fachlichkeit auch nach ernsthaftem Versuch nicht klärbar ist oder wenn eine fertige Standardlösung inzwischen dasselbe leistet.

Ein geordneter Abbruch sichert, was verwertbar ist: Anforderungsdokumente, Datenmodelle, Analyseergebnisse, Konzepte und die Erkenntnis, warum es nicht funktioniert hat. Diese Ergebnisse sind der Startvorteil des nächsten Anlaufs – und sie gehen verloren, wenn ein Projekt einfach ausläuft, statt beendet zu werden.

Anbieterwechsel mitten im Projekt

Ein Wechsel ist möglich, aber teuer: Rechnen Sie mit zwanzig bis vierzig Prozent zusätzlichem Aufwand für Einarbeitung, Analyse und Nacharbeit. Er lohnt sich, wenn das Bestehende weiterverwendbar und die Zusammenarbeit zerrüttet ist.

Drei Punkte entscheiden über den Erfolg: eine Übergabephase mit dem alten Anbieter, die bezahlt und vertraglich geregelt ist – ohne sie geht das Wissen verloren; ein technisches Assessment durch den neuen Anbieter vor der Beauftragung, mit einer eigenen Bewertung des Bestands; und vollständiger Zugriff auf Code, Infrastruktur und Dokumentation vor dem Wechsel, nicht danach. Das Vorgehen im Detail steht in Vendor-Lock-in vermeiden und die Agentur wechseln.

Was externe Hilfe kostet

Leistung	Aufwand	Ergebnis
Technisches Assessment	5–15 PT	Bewertung des Bestands, Anteil weiterverwendbar
Projekt-Review (Prozess & Organisation)	3–8 PT	Ursachen, Sofortmaßnahmen, Empfehlung
Interims-Projektleitung	2–4 Tage/Woche	Steuerung während der Stabilisierung
Anforderungsarbeit nachholen	10–30 PT	belastbare Grundlage für Neuvergabe

Bei Tagessätzen von 700 bis 1.200 € im deutschsprachigen Raum kostet die Kombination aus Assessment und Review meist einen niedrigen fünfstelligen Betrag. Gemessen an einem Projektvolumen, das bereits gefährdet ist, ist das die günstigste Entscheidungsgrundlage, die Sie bekommen können. Wichtig: Beauftragen Sie das Assessment bei jemandem, der anschließend nicht die Umsetzung anbietet – sonst bewertet der Gutachter seinen eigenen künftigen Auftrag.

Kurz gefasst

IT-Projekt retten heißt zuerst: die Krise benennen, neue Zusagen stoppen, Fakten und Zugriff sichern und sich einen lauffähigen Stand zeigen lassen. Danach entscheiden vier Fragen über das Weitere – ist die Fachlichkeit klar, taugt das Bestehende, ist die Zusammenarbeit reparabel, rechnet sich die Fortsetzung ab heute. Sanieren Sie über einen radikal gekürzten Umfang und einen nahen, echten Meilenstein statt über zusätzliches Personal. Und sichern Sie parallel Ihre rechtliche Position: Mängel schriftlich rügen, Fristen setzen, Zugriff auf Code und Zugänge herstellen.

Häufige Fragen

Woran erkenne ich, dass mein IT-Projekt gerettet werden muss?

Am zuverlässigsten daran, dass Sie keinen lauffähigen Stand vorgeführt bekommen, den Sie selbst bedienen können. Weitere harte Signale: zweimal verschobene Termine ohne Umfangsänderung, wiederkehrende Fehler, ausgetauschte Schlüsselpersonen und Statusberichte, die sich seit Wochen nicht ändern. Ab etwa fünf dieser Signale ist die Krise real.

Sollte man in einer Projektkrise mehr Entwickler einsetzen?

In der Regel nein. Zusätzliches Personal bindet zunächst Kapazität des ohnehin überlasteten Teams für Einarbeitung und verschärft die Lage kurzfristig. Wirksamer sind ein radikal gekürzter Umfang, kürzere Entscheidungswege und ein naher, echter Meilenstein. Aufstocken ergibt erst Sinn, wenn Anforderungen und Architektur stabil sind.

Was kostet die Rettung eines IT-Projekts?

Die Entscheidungsgrundlage – Assessment plus Review – liegt meist bei 8 bis 23 Personentagen, also einem niedrigen fünfstelligen Betrag. Die Sanierung selbst hängt vom Ergebnis ab. Als grobe Orientierung: Ein Anbieterwechsel bei brauchbarem Bestand kostet 20 bis 40 Prozent zusätzlichen Aufwand, ein Neustart der Umsetzung bei erhaltenen Anforderungen 60 bis 80 Prozent des ursprünglichen Umsetzungsbudgets.

Wann sollte man ein IT-Projekt abbrechen?

Wenn der geschäftliche Nutzen entfallen ist, wenn die Kosten ab heute den erwarteten Nutzen übersteigen, wenn die Fachlichkeit auch nach ernsthaftem Versuch nicht klärbar ist oder wenn inzwischen eine Standardlösung dasselbe leistet. Entscheidend ist, ausschließlich mit den Kosten ab heute zu rechnen – bereits ausgegebenes Geld ist für diese Entscheidung ohne Bedeutung.

Kann man die Agentur mitten im Projekt wechseln?

Ja, mit 20 bis 40 Prozent Zusatzaufwand. Voraussetzung sind drei Dinge: eine bezahlte, vertraglich geregelte Übergabephase mit dem bisherigen Anbieter, ein technisches Assessment durch den neuen Anbieter vor der Beauftragung und vollständiger Zugriff auf Code, Infrastruktur und Dokumentation vor dem Wechsel.

Wer trägt die Verantwortung, wenn ein Projekt scheitert?

Rechtlich hängt es am Vertragstyp und daran, wessen Pflichtverletzung nachweisbar ist. Praktisch liegt die Ursache fast immer auf beiden Seiten: unklare Anforderungen und fehlende Entscheidungen auf Auftraggeberseite, unzureichende Warnung und mangelnde Transparenz auf Auftragnehmerseite. Für die Rettung ist die Schuldfrage nachrangig – für die Verhandlung über die Kosten nicht. Dokumentieren Sie deshalb ab dem ersten Krisentag schriftlich.

Hilft ein Interims-Projektleiter?

Häufig ja, besonders bei einer Führungs- oder Strategiekrise. Eine erfahrene externe Person ohne Vorgeschichte im Projekt kann unangenehme Fragen stellen, die intern niemand mehr stellt, und Entscheidungen erzwingen. Zwei bis vier Tage pro Woche über zwei bis drei Monate sind ein üblicher Zuschnitt. Wichtig ist ein klares Mandat mit Entscheidungsbefugnis – ohne das wird daraus eine weitere Berichtsebene.

Weiterführende Ratgeber

• Warum Softwareprojekte scheitern – die Ursachen und wie Sie vorbeugen
• Vendor-Lock-in vermeiden und die Agentur wechseln – der geordnete Anbieterwechsel
• Anforderungen richtig definieren – die Arbeit, die in der Krise nachgeholt werden muss
• Software-Abnahme & Qualitätssicherung – Mängel dokumentieren und Abnahme gestalten
• Gewährleistung & Haftung – welche Ansprüche bestehen
• Zusammenarbeit mit der Agentur – Strukturen, die Krisen verhindern

Anbieter für Assessment und Sanierung: IT-Beratung, Softwareentwicklung, QA & Testing.