Was eine Änderung kostet, je später desto teurer
Dieselbe Änderung kostet in der Konzeption fast nichts und im Live-Betrieb ein Vielfaches. Dieses Kosteneskalations-Prinzip ist einer der stärksten Gründe, warum sich Sorgfalt am Anfang eines Projekts auszahlt. Diese Seite zeigt die belegten Zahlen, macht die Eskalation sichtbar und lässt Sie mit einem Rechner selbst durchspielen, was eine späte Änderung wirklich kostet.
Am Anfang ein Federstrich, am Ende ein Umbau
Eine Änderung ist nicht gleich teuer. Was sie kostet, hängt fast vollständig davon ab, wann sie entdeckt wird. Der Grund ist einfach: Jede spätere Phase setzt auf allem auf, was vorher entstanden ist.
Warum früh so günstig ist
In der Konzeption existiert das System nur auf dem Papier. Eine Anforderung zu ändern heißt hier, ein Dokument anzupassen. Es gibt noch keinen Code, keine Konfiguration, keine Daten und keine Nutzer, die umlernen müssten.
Eine Änderung ist hier ein Federstrich. Sie kostet Minuten, nicht Tage, und betrifft niemanden außerhalb des Konzeptteams.
Warum spät so teuer ist
Im Live-Betrieb betrifft dieselbe Änderung reale Prozesse und reale Daten. Sie erfordert die Anpassung selbst, die Korrektur bereits erfasster Daten, einen neuen Test, die Schulung der Anwender und ein formales Änderungsverfahren.
Aus dem Federstrich wird ein Umbau bei laufendem Betrieb. Dazu kommt das Risiko, dass etwas im Tagesgeschäft ausfällt.
Dieselbe Änderung, fünf Phasen
Die Balken zeigen, wie stark die Kosten einer Änderung mit der Phase steigen, in der sie entdeckt wird. Die Werte sind die belegten Faktoren aus der NASA-Auswertung, bezogen auf die Anforderungsphase als eine Einheit.
Faktoren als Vielfaches der Anforderungsphase. Test- und Betriebswerte nach der NASA-Auswertung, der Betriebswert als Faustregel bis zum Hundertfachen und mehr.
Was kostet Ihre Änderung je Phase?
Stellen Sie ein, was eine Änderung in der Konzeption kosten würde. Der Rechner zeigt sofort, was dieselbe Änderung in jeder späteren Phase kostet, nach den belegten Eskalationsfaktoren.
Änderungskosten-Rechner
Ein illustratives Werkzeug. Es zeigt die Größenordnung, nicht einen exakten Angebotspreis.
Berechnung auf Basis der belegten Eskalationsfaktoren. Konzeption als Startwert, Bau etwa das Dreifache, Test etwa das Fünfzehnfache und Live-Betrieb etwa das Dreißigfache der Konzeptionskosten. Die Faktoren sind gerundete Richtwerte aus öffentlicher Forschung und dienen der Veranschaulichung.
Woher die Zahlen kommen
Die bekannte Zahl vom Hundertfachen stammt ursprünglich aus internen Unterlagen von IBM aus dem Jahr 1981. Ihre exakte Höhe ist umstritten, denn die Originaldaten sind dünn. Das gehört zur Ehrlichkeit dazu.
Unstrittig ist die Richtung. Dass späte Korrekturen dramatisch teurer sind, stützen Auswertungen der NASA, des NIST und die Analyse von über 12.000 Projekten durch Capers Jones. Wir nutzen die belegten Spannen und die Rule of Ten und behandeln die 1 zu 100 als anschauliche Faustregel, nicht als harte Zahl.
Normierte Faktoren je Phase, von 3 bis 8 in der Konzeption bis 21 bis 78 im Test. Die Grundlage der Kurve auf dieser Seite.
Die Analyse von über 12.000 Projekten stützt die Richtung, dass frühe Fehlerbehebung ein Vielfaches günstiger ist.
Die 1 zu 100 ist anschaulich und einprägsam, aber ein Richtwert. Die Aussage braucht die Übertreibung nicht.
Sechs Wege, teure späte Änderungen zu vermeiden
Jeder Hebel verschiebt Entscheidungen und Fehlerfunde in die günstige Frühphase. Zusammen halten sie die Änderungskosten niedrig.
In die Konzeption investieren
Sorgfalt in Prozessanalyse und Soll-Konzept stecken, wo Änderungen am günstigsten sind.
Anforderungen früh prüfen
Konzept mit den späteren Nutzern gegenlesen, um Lücken vor dem Bau zu finden.
Umfang klar festlegen
Einen dokumentierten Umfang definieren, damit Erweiterungen bewusst entschieden werden.
Früh und oft testen
In jeder Phase testen, nicht erst am Ende, solange Fehler günstig zu beheben sind.
Standard vor Anpassung
Nah am Standard bleiben, denn Sonderwege verteuern jede künftige Änderung.
Externen Blick einholen
Ein kritischer Blick von außen macht versteckte Annahmen früh sichtbar.
Häufige Fragen zu Änderungskosten
Kompakte, eigenständige Antworten zum Prinzip, den Zahlen und der Bedeutung für die Auswahl.
Warum wird eine Änderung mit jeder Projektphase teurer?
Weil eine Änderung in einer späten Phase auf allem aufsetzt, was vorher gebaut wurde. In der Konzeption ist eine Änderung nur eine Anpassung im Dokument. Ist das System konfiguriert, erfordert dieselbe Änderung neue Arbeit, einen neuen Test und oft Anpassungen an angrenzenden Stellen. Im Live-Betrieb kommen Datenkorrekturen, Ausfallrisiko, Schulung und Abstimmung hinzu. Jede Phase fügt Aufwand hinzu, den es vorher nicht gab, deshalb steigt der Preis.
Wie stark steigen die Kosten wirklich?
Als Faustregel gilt die Rule of Ten, wonach sich die Kosten je Phase etwa verzehnfachen. Eine belastbare Auswertung der NASA zeigt Spannen: Setzt man einen Fehler in der Anforderungsphase auf eine Einheit, kostet er in der Konzeption rund 3 bis 8 Einheiten, im Bau 7 bis 16, im Test 21 bis 78 und im Betrieb 29 Einheiten und mehr. Die oft zitierte Zahl vom Hundertfachen ist ein Richtwert, keine exakte Größe. Der genaue Faktor hängt vom Projekt ab, die Richtung ist aber breit belegt.
Stimmt die 1 zu 100 Regel wirklich?
Die konkrete Zahl vom Hundertfachen stammt ursprünglich aus internen Unterlagen von IBM aus dem Jahr 1981 und ist in ihrer Genauigkeit umstritten. Was nicht umstritten ist, ist die Richtung: Späte Korrekturen sind dramatisch teurer als frühe. Das wird durch Auswertungen der NASA, des NIST und die Analyse von über 12.000 Projekten durch Capers Jones gestützt. Wir nutzen die 1 zu 100 daher als anschauliche Faustregel und stützen die konkreten Aussagen auf die belegten Spannen.
Was ist die Rule of Ten?
Die Rule of Ten ist eine Merkregel, nach der die Kosten einer Fehlerbehebung mit jeder Projektphase etwa um den Faktor zehn steigen. Kostet eine Korrektur beim frühen Test 100 Euro, sind es bei der Abnahme rund 1.000 Euro und nach dem Release rund 10.000 bis 100.000 Euro. Die Regel stammt ursprünglich aus der Qualitätsforschung in der Fertigung und überträgt sich gut auf Softwareprojekte.
Was bedeutet das für die Softwareauswahl?
Es bedeutet, dass sich Sorgfalt am Anfang doppelt auszahlt. Wer in Prozessanalyse und ein klares Soll-Konzept investiert, findet Lücken, solange ihre Behebung fast nichts kostet. Wer diese Phase überspringt, um schneller zu sein, zahlt dieselben Lücken später zu einem Vielfachen. Die Kosteneskalation ist damit das ökonomische Argument für eine gründliche Vorbereitung vor der Auswahl.
Warum sind Änderungen im Live-Betrieb am teuersten?
Weil im Live-Betrieb reale Daten und reale Prozesse betroffen sind. Eine Änderung erfordert dann nicht nur die Anpassung selbst, sondern auch die Korrektur bereits erfasster Daten, eine erneute Prüfung, Schulung der Anwender und die Abstimmung über ein formales Änderungsverfahren. Zusätzlich droht ein Ausfallrisiko im laufenden Geschäft. Diese Begleitkosten machen späte Änderungen so teuer.
Gilt das nur für große Projekte?
Nein, das Prinzip gilt unabhängig von der Größe. In kleinen Projekten sind die absoluten Beträge niedriger, das Verhältnis bleibt aber gleich, eine späte Änderung kostet ein Vielfaches einer frühen. Gerade im Mittelstand mit knapperen Ressourcen wirkt jeder vermiedene späte Fehler besonders stark, weil er Budget bindet, das an anderer Stelle fehlt.
Wie erkenne ich Fehler früh genug?
Der wirksamste Weg ist, die späteren Nutzer früh einzubinden und Anforderungen und Konzept gemeinsam gegenzulesen, bevor gebaut wird. Ergänzend helfen frühe und wiederholte Tests statt einer einzigen Testphase am Ende sowie ein kritischer Blick von außen, der unbequeme Fragen stellt. Diese Maßnahmen kosten wenig und fangen einen großen Teil der Fehler ab, solange ihre Behebung günstig ist.
Wie hängt das mit der Prozessanalyse zusammen?
Sehr direkt. Die Prozessanalyse ist die Phase, in der Änderungen am günstigsten sind, weil sie nur Dokumente und Konzepte betreffen. Wer hier gründlich arbeitet, verschiebt einen großen Teil der Entscheidungen in die günstige Frühphase. Damit ist die Prozessanalyse nicht nur eine Frage der Qualität, sondern auch der Kosten, denn sie verhindert teure späte Korrekturen.
Wie realistisch ist der Rechner auf dieser Seite?
Der Rechner ist ein illustratives Werkzeug, das die belegten Eskalationsfaktoren anwendet. Er zeigt die Größenordnung, wie stark dieselbe Änderung von Phase zu Phase teurer wird, nicht einen exakten Angebotspreis. Die tatsächlichen Kosten hängen vom konkreten Projekt, der Art der Änderung und der Organisation ab. Als Denkhilfe für die Priorisierung von Sorgfalt in der Frühphase ist er dennoch aussagekräftig.
Sparen Sie am Anfang, nicht am Ende
Die günstigste Änderung ist die, die früh entdeckt wird. Investieren Sie in eine saubere Prozessanalyse und ein klares Konzept, dann bleiben die teuren späten Überraschungen aus.