Softwareprojekt in Schieflage: Entscheidungsbaum für die ersten 14 Tage

Wenn ein IT-Projekt in Schieflage gerät, hat es meist mehrere Wochen unbemerkter Warnsignale hinter sich. Das Meeting, in dem klar wird, dass der Go-live nicht zu halten ist, fühlt sich wie der Anfang der Krise an. Tatsächlich ist es nur der Moment, in dem sie sichtbar wird.

Was in den ersten Tagen einer IT-Projekt-Krise zählt

Die Frage, was zu tun ist, kommt meist zu früh. Zuerst gilt es zu klären, was wir in diesem Moment wirklich wissen und was wir nur zu wissen glauben. Genau deshalb hilft in den ersten Tagen kein Aktionismus. Klassische Krisenprojekt-Praxis setzt zuerst auf ein Lagebild, bevor überhaupt an Meilensteinverschiebungen oder Ressourcenumverteilung gedacht wird (Projekt Magazin, 2015). Wer sofort Termine verschiebt, ohne die Ursache zu kennen, verschiebt oft nur das nächste Scheitern um ein paar Wochen nach hinten.

Die ersten 14 Tage als Entscheidungsbaum

Ein Vorgehen, das sich in der Praxis bewährt hat, gliedert die ersten zwei Wochen in vier Phasen mit je eigenem Ziel. Es ist kein starres Schema, aber ein Gerüst, das verhindert, dass die Krise zur Dauerbeschäftigung wird, statt zu einer Entscheidung zu führen.

1. Tag 1 bis 3, Lagebild. Wer trifft in diesem Projekt tatsächlich Entscheidungen, und wer glaubt nur, es zu tun? Welche Risiken sind dokumentiert, welche kursieren nur als Flurfunk? Ziel dieser Phase ist ein belastbares, schriftliches Bild von Rollen, Risiken und offenen Blockern, keine Bewertung und keine Schuldfrage. Deutscher Consulting beschreibt genau dieses Vorgehen als Standard für die ersten zehn Tage eines Mandats (Deutscher Consulting, 2025).
2. Tag 4 bis 7, Stakeholder und Vertrag. Jetzt folgen Gespräche mit Auftraggeber, Fachbereich und, falls beteiligt, dem externen Dienstleister. Was steht im Vertrag zu Abnahmekriterien und Change-Prozessen? Wo weichen die mündlichen Erwartungen vom schriftlich Vereinbarten ab? Diese Phase legt oft mehr offen als die technische Analyse, weil sich hier zeigt, ob überhaupt Einigkeit darüber besteht, was das Projekt liefern sollte.
3. Tag 8 bis 11, technische Tiefenprüfung. Erst jetzt folgt der Blick in Code, Architektur und Datenmodell. Wie hoch ist die Testabdeckung, wie vollständig sind Schnittstellen dokumentiert, wie viele Workarounds stecken im System, die niemand mehr erklären kann? Diese Phase beantwortet, ob das technische Fundament tragfähig ist oder ob es die eigentliche Ursache der Verzögerung ist.
4. Tag 12 bis 14, Entscheidung. Aus den drei vorangegangenen Phasen entsteht eine von drei Empfehlungen: weiterarbeiten mit angepasstem Plan, das Projekt technisch oder organisatorisch umbauen oder stoppen und neu aufsetzen. Diese Entscheidung gehört schriftlich begründet, mit den konkreten Beobachtungen als Beleg, nicht als Bauchgefühl der verantwortlichen Person.

Warum die Reihenfolge zählt

Der häufigste Fehler in der Praxis steckt in der Reihenfolge am Anfang. Wer mit der technischen Prüfung beginnt, bevor das Lagebild zu Rollen und Erwartungen steht, prüft oft das falsche System, weil unklar ist, was das System eigentlich leisten sollte. Wer stattdessen sofort mit Stakeholdern über Verträge spricht, bevor intern Klarheit über Risiken herrscht, verhandelt aus einer schwachen Position.

Operative Stabilität, also ein Zustand, in dem das IT-Projekt wieder plan- und steuerbar läuft, wird nach diesem Modell erst bis Tag 30 erreicht (Deutscher Consulting, 2025). Die ersten zwei Wochen liefern die Entscheidungsgrundlage. Die Umsetzung braucht danach noch einmal so viel Zeit, oft mehr.

Für die Muster, die im Beitrag warum IT-Projekte scheitern beschrieben sind, gilt das besonders, denn unklare Anforderungen lassen sich nicht nebenbei aufklären.

Was am Ende der 14 Tage konkret steht

Die drei möglichen Ausgänge unterscheiden sich stark in Aufwand und Risiko. Weiterarbeiten mit angepasstem Plan bedeutet meist neue Meilensteine, ein geändertes Reporting an die Geschäftsführung und häufig eine Reduktion des Funktionsumfangs auf das, was zum ursprünglichen Termin wirklich nötig ist. Umbauen betrifft in der Praxis oft die Architektur oder die Teamstruktur, etwa wenn zwei Gruppen parallel am selben Modul arbeiten, ohne dass jemand die Schnittstelle verantwortet. Stoppen ist die seltenste, aber wichtigste Option, wenn die technische Tiefenprüfung zeigt, dass die Grundlage nicht hält.

Ein Neustart klingt nach dem größten Verlust, ist aber manchmal die günstigere Option gegenüber einem IT-Projekt, das monatelang weiter Geld verbrennt, ohne näher ans Ziel zu kommen. Die Kriterien dafür stehen im Beitrag zu Projektrettung oder Neustart.

Wichtig ist, dass diese Entscheidung nicht allein bei der Person liegt, die die 14-Tage-Prüfung durchgeführt hat. Sie liefert die Faktenbasis. Die Entscheidung selbst gehört auf die Ebene, die auch das Budget verantwortet, meist die Geschäftsführung oder die IT-Leitung gemeinsam mit dem Auftraggeber des Projekts.

Häufige Fragen

Wer führt die Analyse in den ersten 14 Tagen durch?

Im Idealfall eine Person mit technischer und organisatorischer Erfahrung, die nicht Teil der bisherigen Projektstruktur war. Interne Verantwortliche stehen oft zu nah an den bisherigen Entscheidungen, um sie unvoreingenommen zu bewerten. Ein Interim CTO übernimmt diese Rolle häufig genau für die Dauer der Prüfung und darüber hinaus.

Soll das Team während der Prüfung weiterarbeiten?

In der Regel ja, an unstrittigen Teilen des Systems, bei denen ein Baustopp nur zusätzliche Kosten ohne Erkenntnisgewinn bedeuten würde. Bei Bereichen, die unmittelbar von der Entscheidung betroffen sind, etwa einer strittigen Architekturkomponente, lohnt sich ein befristeter Stopp, bis die Tiefenprüfung abgeschlossen ist.

Was sagt man dem Team in dieser Phase?

Offenheit über den Prozess wirkt verlässlicher als Beschwichtigung. Ein Team, das weiß, dass eine strukturierte Prüfung mit festem Zeitrahmen läuft und wann eine Entscheidung fällt, arbeitet konzentrierter als eines, das nur Gerüchte über eine mögliche Neuausrichtung hört.

Der nächste Schritt

torck führt die Lagebild-, Stakeholder- und Technikprüfung als Team durch, das anschließend selbst weiterbaut, statt nur einen Bericht zu übergeben. Nach der Entscheidung stehen eigene Entwicklungsteams in Maxhütte-Haidhof, Wien und Rabat bereit, um Umsetzung und technische Führung sofort zu übernehmen. Vereinbaren Sie ein unverbindliches Erstgespräch für Ihre konkrete Projektlage.