Festpreis oder Stundenabrechnung?

Bei einem kleinen TYPO3-Update ist ein Festpreis oft problemlos möglich. Bei größeren oder über Jahre gewachsenen Projekten halte ich dagegen wenig davon, einen Preis zu versprechen, den man technisch noch gar nicht belastbar einschätzen kann.

Mein Grundsatz ist deshalb einfach: Festpreis nur dann, wenn das Projekt wirklich überschaubar ist. In allen anderen Fällen schätze ich den maximal zu erwartenden Aufwand und rechne anschließend nur die tatsächlich geleisteten Stunden ab.

Das gibt dem Kunden einen klaren Kostenrahmen, ohne dass unbekannte Risiken vorsorglich in einen hohen Pauschalpreis eingerechnet werden müssen.

Wann ist ein Festpreis sinnvoll?

Ein Festpreis passt gut zu Projekten, bei denen die Ausgangslage klar ist. Zum Beispiel bei einer kleinen Website mit wenigen oder keinen individuellen Extensions, einer gepflegten technischen Basis, guten Zugängen und nur einem überschaubaren Versionssprung.

Wenn ich nach der ersten Analyse ziemlich genau sehe, was zu tun ist, kann ich den Aufwand auch zuverlässig kalkulieren. Der vereinbarte Preis umfasst dann den gesamten Update-Prozess: von den ersten Änderungen im Code bis zur Abnahme und zum Go-live.

Auch die vereinbarte Nachbetreuung gehört dazu. Ein Festpreis bedeutet also nicht, dass nach dem Deployment plötzlich jede Rückfrage zusätzlich berechnet wird.

Bei größeren Projekten arbeite ich lieber mit einer Maximalschätzung

Bei einem größeren TYPO3-System sieht die Sache anders aus. Wenn viele eigene Extensions, alte Schnittstellen oder schlecht dokumentierte Funktionen vorhanden sind, kann niemand bei einer kurzen Analyse garantieren, wie viele Stunden am Ende tatsächlich nötig werden.

Dann würde ich zum Beispiel sagen:

Ich schätze den Aufwand aktuell auf etwa 100 Stunden. Das ist meine Maximalschätzung auf Basis dessen, was wir heute wissen. Wenn ich darunter bleibe, wird auch nur der tatsächlich benötigte Aufwand berechnet. Wenn sich abzeichnet, dass der Rahmen nicht reicht, spreche ich das vorher mit dir ab.

Das ist für mich transparenter als ein künstlicher Festpreis. Der Kunde kennt den Rahmen und bekommt trotzdem eine stundengenaue Abrechnung.

Warum ich bei großen Legacy-Projekten keinen Festpreis verspreche

Bei alten TYPO3-Projekten gibt es häufig Dinge, die erst während der eigentlichen Arbeit sichtbar werden. Eine undokumentierte Funktion, ein kaum genutzter Import oder eine Extension, die tiefer ins System eingreift als zunächst erkennbar.

Wenn ein Projekt groß und wenig dokumentiert ist, würde ich deshalb keinen Festpreis anbieten. Besteht ein Kunde trotzdem unbedingt darauf, müsste ich das Risiko sehr großzügig einpreisen oder den Auftrag im Zweifel ablehnen.

Ein Festpreis ist nur dann sinnvoll, wenn beide Seiten einigermaßen sicher wissen, was darin enthalten ist.

Was passiert, wenn während des Updates etwas Unerwartetes auftaucht?

Auch bei guter Analyse kann während eines Updates etwas auftauchen, das vorher nicht erkennbar war. Dann arbeite ich nicht einfach weiter und stelle am Ende kommentarlos mehr Stunden in Rechnung.

Ich kläre zuerst, was gefunden wurde, warum es bei der Analyse nicht sichtbar war und welche Auswirkungen es auf das Update hat. Danach besprechen wir, ob die Funktion noch gebraucht wird und welcher zusätzliche Aufwand sinnvoll ist.

Bei einem Festpreis behalte ich mir deshalb vor, bei echten größeren Überraschungen neu über den Umfang zu sprechen. Eine komplett neue oder vorher unbekannte technische Baustelle gehört nicht automatisch in einen Pauschalpreis, nur weil sie im selben TYPO3-System steckt.

Kleine Abweichungen sind etwas anderes. Wenn es nur um eine Formulierung oder eine andere Kleinigkeit geht, die in wenigen Minuten erledigt ist, mache ich daraus kein neues Angebot. Sobald dafür allerdings zusätzliche Entwicklung notwendig ist, ist es keine Kleinigkeit mehr.

Wie transparent ist die Stundenabrechnung?

Bei Projekten nach Aufwand tracke ich meine Arbeitszeit mit Beschreibung. Es ist also nachvollziehbar, woran ich gearbeitet habe und wie viel Zeit dafür angefallen ist.

Auf Wunsch bekommt der Kunde am Ende einen Export dieser Zeiterfassung. Bei größeren Projekten besprechen wir außerdem im regelmäßigen Status-Call, wo wir aktuell stehen, was erledigt wurde und wie sich der verbleibende Aufwand entwickelt.

Der Kunde soll nicht erst auf der Rechnung erfahren, dass ein Projekt deutlich größer geworden ist als ursprünglich gedacht.

Können große Updates in mehrere Phasen aufgeteilt werden?

Ja. Gerade bei sehr großen Updates kann das sinnvoll sein, wenn ein Unternehmen die Kosten über mehrere Monate verteilen möchte oder das Projekt ohnehin in klaren technischen Schritten umgesetzt werden kann.

Ich würde daraus aber keine starren „40-Stunden-Pakete“ machen, bei denen nach Ablauf der Zeit einfach aufgehört wird. Ein Update muss technisch an einem sinnvollen Punkt stehen.

Besser ist eine Aufteilung in Phasen mit einem klaren Zwischenziel. Nach jeder Phase gibt es eine Zusammenfassung: Was wurde erledigt, was wurde zusätzlich gefunden und was steht als Nächstes an?

So kann ein großes Projekt Stück für Stück umgesetzt werden, ohne dass der technische Zusammenhang verloren geht.

Was ist für den Kunden besser?

Bei einem kleinen, klaren Projekt ist ein Festpreis angenehm, weil die Kosten von Anfang an feststehen. Wenn ein Kunde bei einem solchen Projekt trotzdem lieber eine genaue Stundenabrechnung möchte, ist das ebenfalls möglich.

Bei großen Legacy-Projekten ist eine Abrechnung nach Aufwand aus meiner Sicht die sinnvollere Variante. Entscheidend ist dabei nicht das Abrechnungsmodell selbst, sondern dass der Kostenrahmen vorher klar besprochen wird und Änderungen rechtzeitig kommuniziert werden.

Ein günstiger Festpreis, der während des Projekts ständig um Nachträge ergänzt wird, hilft niemandem. Genauso wenig hilft eine offene Stundenabrechnung ohne regelmäßige Rückmeldung zum aktuellen Stand.

Meine Faustregel

Je überschaubarer das TYPO3-Projekt, desto eher ist ein Festpreis sinnvoll. Je größer, älter und unbekannter das System ist, desto sinnvoller ist eine transparente Abrechnung nach tatsächlichem Aufwand mit einer vorherigen Maximalschätzung.