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.

Beide Seiten können jederzeit aufhören. Monatlich kündbar. Das ist die unbequemste und zugleich wichtigste Eigenschaft: Wir müssen jeden Monat aufs Neue begründen, warum es sich lohnt. Ein Projektvertrag mit zwölf Monaten Laufzeit nimmt einem diesen Druck ab — und das merkt man der Arbeit an.

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.