Diesen Satz habe ich in Projekten schon oft gehört. Und jedes Mal schwingt darin dasselbe mit: Unsicherheit. Unsicherheit darüber, wie lange etwas wirklich dauert, was es am Ende kosten wird und wer eigentlich das Risiko trägt.
Ich mochte Projektarbeit zu Festpreisen schon immer lieber als Time & Material. Und seit ich wieder in der internen Softwareentwicklung arbeite und regelmäßig mit Agenturen und externen Anbietern zu tun habe, fühle ich mich darin nur noch mehr bestätigt.
Ich brauche keine hochkomplexen Kalkulationen, um das Risiko eines Projekts zu bewerten. Ein Festpreis zwingt automatisch dazu, sich früh Gedanken zu machen: Was ist wirklich Teil des Projekts, was nicht, und wo liegen die Unsicherheiten? Gerade auf Kundenseite ist das ein enormer Vorteil. Freigaben zu bekommen ist viel einfacher, wenn nicht ständig die Frage im Raum steht, was passiert, wenn das Projekt fast fertig ist, aber doch noch mehr Geld benötigt wird – und ob es sich dann überhaupt noch lohnt, weiterzumachen.
Auch in der Rolle des Anbieters ziehe ich Festpreise klar vor. Ich weiß von Anfang an, was ich verdienen werde und wie lange ein Projekt maximal dauern darf. Dadurch lasse ich mich nicht auf Endlosprojekte ein, bei denen zwar kontinuierlich Geld fließt, aber kein Ende in Sicht ist. Nachverhandlungen entfallen ebenfalls, weil der finanzielle Rahmen klar ist und sich daran nichts mehr ändert.
Diese Klarheit hat einen wichtigen Nebeneffekt: Ich muss selbst sauber planen. Eigene Unzulänglichkeiten lassen sich nicht einfach auf den Kunden abwälzen, indem man sagt, dass alles eben länger dauert und deshalb mehr kostet. Gleichzeitig nimmt ein Festpreis dem Kunden sehr viel Unsicherheit. Selbst wenn etwas nicht ideal läuft, steigen die Kosten nicht plötzlich. Diese Sicherheit ist Kunden auch Geld wert. Viele zahlen lieber etwas mehr, als später intern erneut Prozesse durchlaufen zu müssen, um zusätzliches Budget freizugeben.
Natürlich hat Time & Material seine Berechtigung. In der Praxis verleitet dieses Modell jedoch schnell zu problematischem Verhalten. Häufig wird nicht ausreichend geplant oder spezifiziert, weil Vorleistungen nicht bezahlt werden und man möglichst schnell abrechenbare Stunden generieren möchte. Neue Anforderungen werden gerne noch in laufende Projekte aufgenommen, weil sie vielleicht noch ins geplante Budget passen könnten. In der Realität tun sie das nie. Beim Festpreis ist hingegen klar, dass zusätzliche Anforderungen extra kosten – und vor allem auch, wie viel genau.
Time & Material ermöglicht außerdem Preis-Dumping, weil kein Risiko eingepreist werden muss. Beim Festpreis werden sowohl der Initialaufwand als auch ein Puffer berücksichtigt. Bei Time & Material wird dagegen oft gehofft, diesen Initialaufwand über die Laufzeit des Projekts zu kompensieren. Wenn alles länger dauert, ist das erst einmal egal, denn der Kunde zahlt weiter – zumindest so lange, bis er sich weigert oder das Ganze juristisch eskaliert.
Ein weiterer Punkt, der mir beim Festpreis wichtig ist, betrifft die eigene Freiheit in der Zeitplanung. Dem Kunden ist es egal, wie lange ich tatsächlich brauche oder wann ich arbeite. Ich liefere ein Feature, keine Arbeitszeit. Natürlich kann auch ein Festpreisprojekt grob zeitlich eingeordnet werden, und das ist oft sinnvoll, damit der Kunde weiß, wann er womit rechnen kann. Der entscheidende Unterschied ist jedoch, dass der Druck nur auf der Auslieferung liegt und nicht darauf, möglichst wenig Zeit zu bezahlen.
Sollte etwas deutlich schneller gehen als gedacht, kann man immer noch einen Rabatt gewähren. Das freut den Kunden und stärkt die Beziehung. Die Kontrolle bleibt dabei trotzdem beim Anbieter, und der Kunde kann keinen Druck aufbauen in der Hoffnung, durch Verzögerungen weniger zahlen zu müssen.
Mein persönliches Fazit – gerade auch mit Blick auf neue Arbeitsweisen und KI – ist daher recht klar: Es geht um den Wert eines Features, nicht um die Zeit, die seine Umsetzung gebraucht hat. Wenn jemand eine sehr gute Idee hat und dadurch extrem schnell liefert, ist das oft mehr wert als eine Lösung, die länger braucht. Eigentlich sollte dann auch genau diese Leistung besser bezahlt werden.
Lass dir Schnelligkeit und Qualität bezahlen, nicht die Tatsache, dass du besonders lange an einem Feature arbeitest. Gib dem Kunden die Kontrolle über das Projekt zurück. Denn je geringer das Risiko ist, desto entspannter – und am Ende auch besser – arbeiten alle Beteiligten.