IT-Projekte brauchen Abbruchkriterien, bevor sie starten

Ein IT-Projekt liegt hinter dem Zeitplan, benötigt zusätzliches Budget und liefert weniger als ursprünglich erwartet. Trotzdem lautet die Entscheidung häufig: weitermachen. Schließlich wurde bereits viel investiert, Verträge wurden geschlossen und ein Abbruch müsste erklärt werden.

Gerade diese Begründung ist wirtschaftlich gefährlich. Vergangene Ausgaben werden durch Fortsetzung nicht zurückgewonnen. Für die nächste Entscheidung zählen erwarteter Restnutzen, verbleibender Aufwand, aktuelle Risiken und verfügbare Alternativen.

Ein Projekt sollte deshalb nicht erst in der Krise über seine Abbruchbedingungen sprechen. Vor dem Start muss geklärt sein, welche Beobachtungen zu Fortführung, Kursänderung, Pause oder Beendigung führen.

Ein Abbruch ist eine Steuerungsoption, kein Schuldeingeständnis

Projekte beginnen unter Unsicherheit. Nutzerbedarf, technische Machbarkeit, Datenqualität, Integrationen, Akzeptanz und Kosten lassen sich nicht vollständig vorhersagen. Neue Erkenntnisse sind deshalb kein Beweis schlechter Planung. Sie sind der Zweck einer schrittweisen Umsetzung.

Problematisch wird Unsicherheit, wenn jede neue Information nur den Plan verlängert. Dann schützt das Projekt seinen ursprünglichen Beschluss, statt weiterhin die beste Entscheidung für das Unternehmen vorzubereiten.

Vier Ergebnisse müssen grundsätzlich möglich sein:

• Fortführen: Die Annahmen tragen ausreichend und der nächste Schritt ist wirtschaftlich begründet.
• Verändern: Ziel, Umfang, Lösung oder Vorgehen werden aufgrund neuer Erkenntnisse angepasst.
• Pausieren: Eine externe Voraussetzung oder Entscheidung fehlt; weitere Ausgaben würden vorerst keinen Erkenntnisgewinn erzeugen.
• Beenden: Der erwartete Nutzen rechtfertigt Restaufwand und Risiko nicht mehr oder eine bessere Alternative ist verfügbar.

Wenn nur „Fortführen“ als akzeptables Ergebnis gilt, ist ein Review kein Entscheidungszeitpunkt, sondern Berichtspflicht.

Fortschritt und Erfolg sind verschiedene Größen

Ein Projekt kann viele Arbeitspakete abschließen und dennoch am Geschäftsziel vorbeilaufen. Erledigte Tickets, verbrauchtes Budget und erreichte Meilensteine beschreiben Aktivität. Sie belegen nicht automatisch Wirkung.

Für eine Fortführungsentscheidung braucht es zwei Sichten:

1. Lieferfähigkeit: Kann das Team die vereinbarte Lösung mit vertretbarem Restaufwand und Risiko bereitstellen?
2. Wirkung: Ist diese Lösung nach heutigem Wissen noch geeignet, den relevanten Nutzen zu erzeugen?

Der Green Book-Stand 2026 ordnet Vorhaben über Begründung, Ziele, Optionen, Monitoring, Evaluation und Rückkopplung. Die Vorgaben sind für britische öffentliche Ausgaben entwickelt worden und nicht unmittelbar auf ein deutsches mittelständisches Unternehmen anzuwenden. Als Denkrahmen ist jedoch wertvoll, dass eine Investition nicht nur vorab genehmigt, sondern anhand ihrer Wirkungslogik weiter beurteilt wird.

Die Nutzenannahme muss beobachtbar sein

Ein Vorhaben sollte vor dem Start erklären, welche Veränderung es erzeugen soll und welche Annahmen dafür gelten.

Beispielsweise:

• Nutzer können einen Kernvorgang ohne parallele Schattenliste abschließen.
• Ein definierter manueller Prüfaufwand entfällt oder sinkt.
• Fehler werden vor einer nachgelagerten Buchung erkannt.
• Ein sicherheitsrelevanter Altbetrieb kann tatsächlich beendet werden.
• Ein Dienst lässt sich mit den vorhandenen oder geplanten Fähigkeiten betreiben.

Zu jeder Nutzenannahme gehören Ausgangsbasis, erwartete Beobachtung, Datenquelle, verantwortliche Rolle und Zeitpunkt der Prüfung. Fehlt eine belastbare Ausgangszahl, kann zunächst eine Erhebungsphase beschlossen werden. Scheinpräzise Zielwerte sind nicht besser als eine offen benannte Datenlücke.

Die GOV.UK-Anleitung zum Messen von Service-Nutzen empfiehlt, Nutzenmetriken mit Stakeholdern früh zu vereinbaren, Erkenntnisse in das wirtschaftliche Modell zurückzuführen und auf dieser Basis zu entscheiden, ob ein Service in die nächste Phase geht, verändert oder beendet wird.

Abbruchkriterien sind keine einzelne rote Linie

Ein starres Kriterium wie „zehn Prozent Budgetüberschreitung“ kann die falsche Sicherheit erzeugen. Eine geringe Überschreitung kann bei hohem verbleibendem Nutzen vertretbar sein. Umgekehrt kann ein Projekt im Budget liegen und trotzdem keinen sinnvollen Nutzen mehr besitzen.

Eine belastbare Entscheidung betrachtet mehrere Dimensionen:

Dimension	Leitfrage
Nutzen	Ist die erwartete Wirkung weiterhin relevant und mit ausreichender Wahrscheinlichkeit erreichbar?
Nutzung	Akzeptieren die betroffenen Rollen den neuen Arbeitsweg unter realen Bedingungen?
Machbarkeit	Sind kritische Technik-, Daten- und Integrationsannahmen belegt?
Restaufwand	Welche internen und externen Kosten entstehen ab heute bis zum nutzbaren Betrieb?
Betrieb	Sind Support, Sicherheit, Verantwortung und laufende Fähigkeiten tragfähig?
Risiko	Welche wesentlichen Risiken sind neu, gestiegen oder nicht mehr beherrschbar?
Alternativen	Gibt es inzwischen einen einfacheren, günstigeren oder reversibleren Weg?
Ausstieg	Welche Ergebnisse, Daten, Verträge oder Komponenten bleiben bei einem Stopp nutzbar?

Nicht jede negative Abweichung beendet das Projekt. Sie erzwingt eine ausdrücklich verantwortete Entscheidung.

Entscheidungszeitpunkte gehören in Finanzierung und Vertrag

Ein Review entfaltet wenig Wirkung, wenn das gesamte Budget bereits gebunden, eine langfristige Lizenz aktiviert und der Dienstleister ausschließlich für Vollumsetzung vergütet ist.

Deshalb sollten Vorhaben soweit möglich in entscheidbare Abschnitte gegliedert werden:

• Problem und Ausgangsbasis prüfen,
• kritische fachliche und technische Annahmen testen,
• einen begrenzten End-to-End-Ablauf mit realistischen Daten erproben,
• Betriebs- und Migrationsfähigkeit nachweisen,
• erst danach breiter ausrollen.

Die Abschnitte benötigen jeweils eine zu beantwortende Frage und ein nutzbares Ergebnis. Eine Phase „Konzept abgeschlossen“ ist schwach, wenn das Konzept die entscheidende Unsicherheit nicht reduziert.

Der GAO Agile Assessment Guide beschreibt inkrementelle Entwicklung und laufende Bewertung von Funktion, Qualität und Kundenzufriedenheit als Mittel zur Risikoreduktion. Der Leitfaden richtet sich an US-Behörden; die übertragbare Einsicht ist, dass kleine überprüfbare Liefergegenstände bessere Steuerungsinformationen liefern als ein langer Projektstatus ohne nutzbares Ergebnis.

Konstruiertes Beispiel: Der erfolgreiche Pilot widerlegt den Rollout

Das folgende Beispiel ist konstruiert.

Ein Unternehmen pilotiert eine Plattform zur automatischen Klassifizierung eingehender Dokumente. Die technische Erkennung funktioniert in der ausgewählten Dokumentengruppe. Im Pilot zeigt sich jedoch, dass die nachgelagerten Fachprüfungen wegen unklarer Stammdaten fast unverändert bleiben. Gleichzeitig würde der breite Rollout zusätzliche Integrationen und dauerhafte Qualitätssicherung erfordern.

Der Pilot ist technisch erfolgreich, aber die ursprüngliche Nutzenannahme trägt nicht ausreichend. Das Unternehmen beendet nicht zwingend jede Nutzung. Es kann den Einsatz auf einen klar begrenzten Fall reduzieren, die Stammdaten zuerst verbessern oder das Vorhaben stoppen.

Ohne vorab vereinbarten Entscheidungszeitpunkt würde derselbe Befund leicht als „Pilot abgeschlossen“ und damit als Begründung für den Rollout gelesen.

Die Stop-or-Go-Karte

Für den Mittelstand genügt häufig eine Seite pro Entscheidungszeitpunkt.

Feld	Inhalt
ursprüngliches Ziel	Welche geschäftliche Wirkung wurde beschlossen?
heutiger Beleg	Welche Ergebnisse und Beobachtungen liegen tatsächlich vor?
widerlegte Annahmen	Was gilt nach heutigem Wissen nicht mehr?
Restnutzen	Welche Wirkung ist noch realistisch erreichbar?
Restkosten	Welche einmaligen und laufenden Aufwände entstehen ab heute?
kritische Risiken	Was kann Nutzen, Termin, Betrieb oder Sicherheit noch verhindern?
Optionen	Fortführen, Umfang ändern, Lösung wechseln, pausieren oder beenden
Ausstiegsfolgen	Welche Verträge, Daten, Komponenten und Pflichten bleiben?
Empfehlung	Welche Option ist warum vorzuziehen?
Entscheidung	Wer entscheidet bis wann und mit welchem dokumentierten Ergebnis?

Wichtig ist der zeitliche Blick nach vorn. Bereits ausgegebene Mittel werden dokumentiert, dürfen aber nicht als Nutzen der Fortsetzung gezählt werden.

Wann ein formales Gate übertrieben ist

Eine kleine, reversible Änderung braucht kein Lenkungsgremium. Ein Product Owner kann nach jeder kurzen Iteration entscheiden, ob der nächste Schritt noch sinnvoll ist. Die Logik bleibt dieselbe: neue Erkenntnisse verändern die Entscheidung.

Formellere Gates sind angemessen, wenn hohe Beträge gebunden werden, ein schwer kündbarer Vertrag bevorsteht, ein Altverfahren abgeschaltet werden soll, mehrere Bereiche umstellen müssen oder wesentliche Sicherheits- und Betriebsrisiken bestehen.

Der Business Case nach dem Go-live betrachtet die spätere Nutzenkontrolle. Abbruchkriterien ergänzen diese Perspektive während des Vorhabens. Sie schützen nicht vor jeder Fehlentscheidung, aber sie verhindern, dass fehlende Entscheidungsregeln automatisch zur Fortsetzung führen.

Ein gutes Projekt muss nicht beweisen, dass die erste Idee richtig war. Es muss dem Unternehmen früh genug zeigen, welcher nächste Einsatz von Zeit, Geld und Aufmerksamkeit noch gerechtfertigt ist.