Warum wir keine Festpreis-Projekte mehr machen

Die Frage kommt in jedem Erstgespräch: „Was kostet das denn — als Projekt?” Die ehrliche Antwort lautet inzwischen: So verkaufen wir das nicht mehr. Nicht aus Bequemlichkeit, sondern weil wir es lange genug anders versucht haben.

Der eingebaute Fehler des Projektvertrags

Ein Festpreis setzt voraus, dass jemand vorher weiß, was gebaut werden soll. Bei klassischer Software geht das oft — eine Rechnungsstellung hat einen beschreibbaren Umfang. Bei Anwendungen, die auf gewachsenen Unternehmensdaten arbeiten, geht es fast nie.

Der Grund liegt nicht am Vertrag, sondern an der Sache: Das Verständnis für das eigentliche Problem entsteht erst beim Bauen. In Woche drei stellt sich heraus, dass die Stammdaten zwei konkurrierende Kundennummern führen. In Woche fünf merkt jemand aus dem Vertrieb, dass die Anwendung ein Problem löst, an das im Konzept niemand gedacht hat — und dass die eigentlich beauftragte Funktion gar nicht so wichtig war.

In einem Festpreisprojekt sind das zwei schlechte Nachrichten. Die erste kostet Geld, das nicht eingeplant war. Die zweite ist noch teurer: Die gute Idee wird abgewiesen, weil sie „nicht im Umfang” ist. Beide Seiten verteidigen ein Dokument, das mit der Wirklichkeit nichts mehr zu tun hat.

Der Festpreis schützt nicht vor Mehrkosten. Er verlagert sie nur in eine Auseinandersetzung, die niemand gewinnt.

Was Abrechnung nach Aufwand nicht besser macht

Der naheliegende Gegenentwurf — einfach nach Stunden abrechnen — dreht das Risiko nur um. Jetzt trägt es der Auftraggeber allein: Läuft es schlecht, zahlt er länger. Und er muss glauben, dass der Anbieter ein Interesse daran hat, schnell fertig zu werden.

Dazwischen entsteht eine seltsame Dynamik. Der Anbieter dokumentiert Stunden, der Kunde prüft Stunden, und beide reden über Aufwand statt über das Produkt.

Was wir stattdessen machen

Eine monatliche Pauschale mit einem festen Kontingent an Entwicklungszeit. Das klingt nach einem Detail, ändert aber die Zusammenarbeit an vier Stellen grundlegend.

Der Umfang darf sich ändern. Was im ersten Monat wichtig schien und im dritten überholt ist, wird nicht gebaut. Stattdessen kommt das rein, was sich inzwischen als das eigentliche Problem herausgestellt hat. Es gibt keinen Änderungsantrag, weil es nichts zu ändern gibt — der Auftrag lautet „weiterentwickeln”, nicht „Anlage 3 umsetzen”.

Die Kosten sind planbar. Gleicher Betrag jeden Monat. Für die Geschäftsführung ist das eine Zeile im Budget statt einer Investitionsentscheidung mit Nachtragsrisiko.

Der Betrieb ist Teil derselben Vereinbarung. Kein Projektende, nach dem niemand mehr zuständig ist. Überwachung, Aktualisierung und Fehlerbehebung laufen weiter, weil die Zusammenarbeit weiterläuft.

Die Zusammenarbeit ist auf Jahre angelegt. Deshalb arbeiten wir bewusst mit wenigen Unternehmen gleichzeitig. Wer ein System über Jahre begleitet, kennt die Stammdaten, die Sonderfälle und die Menschen, die damit arbeiten — und muss sich nicht bei jedem neuen Vorhaben erst wieder einarbeiten.

Die offensichtliche Sorge

„Dann arbeiten Sie doch einfach langsam und kassieren ewig.”

Der Einwand ist berechtigt, und die Antwort steht im vorigen Absatz: Weil monatlich gekündigt werden kann, ist Langsamkeit das schlechteste Geschäftsmodell, das wir wählen könnten. Wer nach drei Monaten nichts Brauchbares geliefert hat, hat keinen Kunden mehr. Der Anreiz zeigt in dieselbe Richtung wie beim Kunden: früh etwas Benutzbares, dann stetig besser.

Dazu kommt eine Selbstverpflichtung, die wir in jedes Angebot schreiben: Nach spätestens sechs Wochen arbeitet jemand mit einer echten Version. Nicht mit einem Klickmodell, sondern mit etwas, das auf echten Daten läuft. Wenn das nicht gelingt, stimmt etwas Grundsätzliches nicht — und dann sollte man aufhören, nicht weiterzahlen.

Wo Festpreise weiterhin sinnvoll sind

Es gibt sie, und wir machen sie auch:

• Abgegrenzte Einzelaufgaben. Eine Schnittstelle zu einem dokumentierten System, ein Datenimport mit bekanntem Format, eine Migration.
• Bestandsaufnahmen. Ein Blick auf vorhandene Software mit schriftlicher Einschätzung, ob Weiterbauen oder Neubau günstiger ist.
• Machbarkeitsfragen. Zeitlich begrenzt, mit Festpreis auf den Aufwand, nicht auf das Ergebnis. Das Ergebnis darf auch lauten: geht nicht.

Was diese Fälle gemeinsam haben: Der Umfang ist vorher wirklich beschreibbar. Wo das zutrifft, ist ein Festpreis das ehrlichere Angebot.

Kurz gefasst

Der Streit über Preismodelle ist ein Streit darüber, wer das Risiko unklarer Anforderungen trägt. Bei KI-Anwendungen ist die Unklarheit kein Versäumnis, sondern die Ausgangslage — sie löst sich erst beim Bauen auf. Ein Modell, das laufende Erkenntnis zulässt statt sie zu bestrafen, ist deshalb nicht der bequemere Weg, sondern der sachlich richtige.

Wovon der Aufwand bei eigener Software tatsächlich abhängt, steht unter Individualsoftware entwickeln lassen.