Warum IT-Projekte scheitern: sieben Warnsignale
Sieben Signale zeigen früh, dass ein IT-Projekt kippt: wachsender Umfang, keine Demos, vage Berichte, offene Entscheidungen, Wissen bei einer Person, wiederkehrende Fehler, schwindendes Budget. Treten zwei davon zugleich auf, helfen Stopp, Inventur und ein neuer Schnitt.
Ein Projekt kann über Wochen in Schieflage geraten, ohne dass es jemand ausspricht. Es sammeln sich kleine Abweichungen, die jede für sich erklärbar wirken: eine verschobene Abnahme, ein Bericht ohne Datum, eine Frage, die niemand beantwortet. Wenn die Geschäftsführung den Stand erfährt, können Budget und Geduld schon zum großen Teil verbraucht sein.
Die sieben Signale unten sind so gewählt, dass auch Auftraggeber ohne technische Ausbildung sie prüfen können. Zu jedem gehört eine Frage, die Sie in der nächsten Projektbesprechung stellen und deren Antwort Sie nachprüfen können. Für KI-Vorhaben gibt es eigene Ursachen, etwa fehlende Daten oder ein Pilot ohne Weg in den Alltag; sie stehen unter Warum KI-Projekte scheitern: fünf typische Ursachen.
Diagnose
Sieben Signale, die vor der Eskalation auftauchen
1. Der Umfang wächst, der Termin bleibt
Neue Wünsche kommen dazu, ohne dass etwas anderes wegfällt oder Preis und Termin angepasst werden. Prüffrage: Welche Anforderungen sind seit dem Start dazugekommen, und welche wurden dafür gestrichen oder neu bepreist?
2. Es gibt nichts zum Anklicken
Fortschritt wird beschrieben, aber nicht gezeigt. Prüffrage: Wann haben Sie zuletzt selbst eine neue Funktion auf einem Testsystem bedient?
3. Berichte werden länger und vager
Statusberichte wachsen, während konkrete Aussagen verschwinden. Ein Modul steht seit Wochen bei „90 Prozent“. Prüffrage: Welche Funktion ist seit dem letzten Bericht fertig und abgenommen?
4. Entscheidungen bleiben liegen
Offene Fragen warten auf eine Antwort, auch auf Auftraggeberseite: Wer legt fest, welche Felder ein Formular hat, wer gibt Texte frei, wer entscheidet über eine Schnittstelle? Prüffrage: Wie viele Fragen sind länger als eine Woche offen, und bei wem liegen sie?
5. Wissen hängt an einer Person
Nur ein Entwickler kann ausliefern, nur er kennt die Zugänge. Wechselt er oder fällt er aus, steht das Projekt. Prüffrage: Wer außer dieser Person hat die Anwendung schon einmal auf den Server gebracht? Wie Sie das absichern, steht unter Bus-Faktor: Was passiert, wenn Ihr einziger Entwickler ausfällt?.
6. Behobene Fehler kehren zurück
Ein Fehler ist gemeldet, behoben und taucht zwei Lieferungen später wieder auf. Das kann auf fehlende automatische Tests und auf Abkürzungen im Code hindeuten, die jede weitere Änderung verteuern; mehr dazu in Technische Schulden erklärt für Geschäftsführer. Prüffrage: Wie viele bereits behobene Fehler sind in den letzten drei Lieferungen erneut gemeldet worden?
7. Das Budget schwindet schneller als der Fortschritt
Rechnungen kommen pünktlich, Meilensteine nicht. Prüffrage: Welcher Anteil des Budgets ist verbraucht, und welcher Anteil der Meilensteine ist abgenommen? Eine Beispielrechnung: Von 60.000 Euro Budget sind 42.000 Euro abgerechnet, also 70 Prozent. Abgenommen sind 3 von 10 Meilensteinen, also 30 Prozent. Unter der Annahme, dass die restlichen Meilensteine gleich viel kosten wie die ersten drei, ergeben 42.000 Euro geteilt durch 0,3 hochgerechnet 140.000 Euro Gesamtkosten, mehr als das Doppelte des Plans.
Ein einzelnes Signal kann Zufall sein. Treten zwei oder mehr gleichzeitig auf, ist das ein Anlass für die erste Hilfe weiter unten.
Signal 1
Wachsender Umfang: wenn jede Woche etwas dazukommt
Scope Creep bezeichnet das schleichende Wachstum des Projektumfangs ohne geregelte Anpassung von Preis, Termin oder Prioritäten. Jede einzelne Ergänzung ist klein: ein weiteres Feld, ein zusätzlicher Export, eine Rolle mehr im Rechtesystem. In der Summe verschieben sie den Termin, und weil niemand die Verschiebung beschlossen hat, fühlt sich auch niemand dafür zuständig.
Das Gegenmittel ist ein fester Weg für Änderungen. Jeder neue Wunsch wird aufgeschrieben, bewertet und mit Aufwand und Folge für den Termin entschieden: aufnehmen und bezahlen, gegen etwas anderes tauschen oder auf eine spätere Etappe verschieben. Wie das in einem Festpreisprojekt mit Meilensteinen und Abnahmekriterien geregelt wird, steht unter Festpreis für Webprojekte: Meilensteine und Abnahmekriterien festlegen.
Dass kleine, abgenommene Etappen den Umfang zusammenhalten, zeigt die Fallstudie zu einem Online-Portal mit zwei CMS unter einem Dach, eines der frühen Festpreisprojekte von MARCODES: Das Projekt war in zehn klar definierte Meilensteine geteilt, mit eindeutigen Abnahmekriterien pro Rate, und jeder Schritt wurde abgenommen, bevor der nächste begann.
Signale 2 und 3
Fehlende Demos und wachsende Statusberichte
Ein Bericht kann beschreiben, was angeblich fertig ist. Eine laufende Funktion auf einem Testsystem, die der Auftraggeber selbst bedient, zeigt es. Deshalb ist der Abstand zwischen zwei sichtbaren Ergebnissen eine Kennzahl, die auch Auftraggeber ohne technische Ausbildung prüfen können.
Welcher Rhythmus passt, ob feste Sprints oder Demo-Zyklen ohne feste Länge, hängt von Teamgröße und Vorhaben ab. Wie ein Takt aus Demo-Zyklen statt festen Sprint-Längen aussehen kann, steht in Sprint-Wahnsinn. Warum Sprints bei uns kein Standard sind. Für das Warnsignal zählt, dass Ergebnisse regelmäßig sichtbar werden und dass Sie sie selbst anklicken können.
Wachsende Statusberichte sind das Spiegelbild fehlender Demos. Achten Sie auf Formulierungen ohne prüfbaren Inhalt: „in Arbeit“, „fast fertig“, „technische Herausforderungen“. Bitten Sie dann um zwei Listen: was seit dem letzten Bericht abgenommen wurde und was bis zum nächsten Termin vorführbar sein wird. Bleibt die erste Liste zweimal hintereinander leer, ist das Signal bestätigt.
Gegenmaßnahme
Erste Hilfe: Stopp, Inventur, neuer Schnitt
Ein Projekt in Schieflage kann gerettet werden, solange Code, Zugänge und Wissen greifbar sind. Die Rettung beginnt mit drei Schritten.
Stopp: Für die Dauer von Inventur und neuem Schnitt kommen keine neuen Funktionen hinzu. Behoben werden nur Fehler, die den Betrieb oder die Daten gefährden. Diese Pause schafft die Zeit für die nächsten beiden Schritte.
Inventur: Was ist fertig und abgenommen, was ist begonnen, was fehlt? Wo liegt der Code, wem gehören Server, Domain und Repository, wer hat welche Zugänge? Welcher Teil des Budgets ist verbraucht? Das BGB kennt für den Fall einer Kündigung aus wichtigem Grund eine gemeinsame Feststellung des Leistungsstandes (§ 648a Abs. 4); dieselbe Bestandsaufnahme lohnt auch ohne Kündigung, weil sie beide Seiten auf denselben Stand bringt.
Neuer Schnitt: Aus der Inventur entsteht der kleinste Umfang, der für den Betrieb nützlich ist, aufgeteilt in Etappen mit Abnahmekriterien. Alles andere wandert auf eine Liste für später.
Am Ende steht eine von drei Entscheidungen: mit demselben Team und neuem Schnitt weitermachen, das Team wechseln und den vorhandenen Code übernehmen, oder einzelne Teile neu bauen. Welche passt, hängt an der Qualität des Codes und an der Zusammenarbeit.
Begleitung
Wann eine externe Projektbegleitung hilft
Hilfe von außen bringt vor allem dann etwas, wenn Auftraggeber und Umsetzungsteam nicht mehr dieselbe Sprache sprechen: Die Geschäftsführung versteht die technischen Begründungen nicht, das Team fühlt sich mit unklaren Anforderungen allein gelassen. Eine Projektbegleitung als technische Brücke zwischen Auftraggeber und Umsetzungsteam übersetzt in beide Richtungen und kann Inventur und neuen Schnitt moderieren; als Anlässe nennt die Seite ausdrücklich Eskalationen und Übernahmen.
Sinnvoll ist das auch vor einer Übernahme durch einen neuen Dienstleister. Eine unabhängige Bestandsaufnahme hilft zu verhindern, dass das neue Team den alten Zustand schönredet oder schlechtredet, je nachdem, ob es einen Neubau verkaufen will.
Vertrag
Wer haftet, wenn ein Softwareprojekt scheitert
Wer haftet, entscheidet zuerst der Vertragstyp. Im Werkvertrag schuldet der Unternehmer einen Erfolg (§ 631 BGB), mit Abnahme und Mängelrechten; im Dienstvertrag schuldet er die Tätigkeit (§ 611 BGB), und Schadensersatz setzt dort eine Pflichtverletzung voraus, die er zu vertreten hat (§ 280 Abs. 1). Maßgeblich ist die vereinbarte Leistung, gleich wie der Vertrag überschrieben ist.
Auch der Auftraggeber hat Pflichten. Ist für das Werk seine Mitwirkung nötig, etwa Inhalte, Zugänge oder Entscheidungen, und bleibt sie aus, kann der Unternehmer nach § 642 eine Entschädigung verlangen und nach § 643 nach Fristsetzung kündigen. Signal 4 aus der Liste oben hat damit eine rechtliche Seite.
Will der Auftraggeber einen Werkvertrag beenden, kann er nach § 648 bis zur Vollendung jederzeit kündigen. Der Unternehmer behält dann die vereinbarte Vergütung abzüglich ersparter Aufwendungen; vermutet wird, dass ihm 5 Prozent der Vergütung für den noch nicht erbrachten Teil zustehen. Bei einem Festpreis von 80.000 Euro, von dem Leistungen für 30.000 Euro erbracht sind, entfallen 50.000 Euro auf den offenen Teil; die Vermutung ergibt dafür 2.500 Euro, zusammen mit den erbrachten Leistungen also 32.500 Euro. Aus wichtigem Grund können beide Seiten nach § 648a ohne Frist kündigen, auch nur für einen abgrenzbaren Teil des Werks.
Zwei Signale gefunden: Wie geht es weiter?
Im Architecture Rescue sehen wir uns Ihr Projekt 60 Minuten lang an und übergeben einen Maßnahmenplan mit drei Punkten, mit dem Sie über Stopp, Inventur und neuen Schnitt entscheiden können.
Nachweise
Quellen und Stand
Stand: 16.07.2026. Die Hinweise zu Vertragstypen und Haftung beschreiben die Rechtslage zum genannten Datum allgemein und sind keine Rechtsberatung.
gesetze-im-internet.de: § 280 BGB, Schadensersatz wegen Pflichtverletzung
gesetze-im-internet.de: § 642 BGB, Mitwirkung des Bestellers
gesetze-im-internet.de: § 643 BGB, Kündigung bei unterlassener Mitwirkung
gesetze-im-internet.de: § 648 BGB, Kündigungsrecht des Bestellers
gesetze-im-internet.de: § 648a BGB, Kündigung aus wichtigem Grund
Artikel teilen