Festpreis oder Aufwand? Softwareprojekte richtig beauftragen

Ob ein Softwareprojekt zum Festpreis oder nach Aufwand beauftragt werden sollte, hängt vor allem an einer Frage: Wie genau weiss man heute, was am Ende gebaut werden muss? Ist der Umfang klar und stabil, schützt ein Festpreis das Budget. Ist er unsicher, was bei neuen digitalen Produkten fast immer der Fall ist, wird ein Festpreis teuer oder führt zu Streit, und eine Abrechnung nach Aufwand mit Kostendach oder ein fest begrenzter erster Schritt ist die ehrlichere Wahl.

Hinter dieser Frage steckt eine zweite, die oft vermischt wird: die Arbeitsweise. Ein Projekt, das nach dem Wasserfall-Modell geplant ist, also alle Anforderungen vorab festlegt und dann in Phasen abarbeitet, passt natürlich zu einem Festpreis. Agile Softwareentwicklung, bei der in kurzen Abschnitten gebaut, gezeigt und nachgesteuert wird, passt natürlicher zu einer Abrechnung nach Aufwand oder zu einem fixen Budget mit beweglichem Umfang. Wer Modell und Arbeitsweise nicht zusammen denkt, unterschreibt eine Offerte, die sich selbst widerspricht.

Dieser Artikel richtet sich an Auftraggeber in Schweizer KMU, die eine Web-App, eine Betriebssoftware oder ein digitales Produkt beauftragen wollen und mehrere Offerten auf dem Tisch haben.

Die drei Modelle im Überblick

Festpreis: wann er schützt und wann er teuer wird

Ein Festpreis gibt Planungssicherheit. Man weiss vor Projektstart, was das Projekt kostet, und muss sich nicht um Stundenzettel kümmern. Für Vorhaben mit klaren, stabilen Anforderungen ist das ideal: eine Website mit bekanntem Seitenumfang, die Migration eines bestehenden Systems mit festem Funktionsumfang, eine Schnittstelle mit dokumentierten Daten auf beiden Seiten.

Der Preis für diese Sicherheit ist dreifach:

• Risikozuschlag. Ein seriöser Anbieter rechnet ein, was schiefgehen kann. Je unklarer der Umfang, desto höher der Zuschlag. Man bezahlt also für Unsicherheit, auch wenn sie nie eintritt.
• Nachträge. Was nicht ausdrücklich im Pflichtenheft steht, ist nicht geschuldet. Jede neue Erkenntnis während des Projekts wird zum Änderungsantrag mit eigenem Preis.
• Falsche Anreize. Bei einem Festpreis hat der Anbieter ein Interesse daran, möglichst genau das Vereinbarte zu liefern, nicht unbedingt das Beste. Das ist kein Vorwurf, sondern die Logik des Modells.

Damit ein Festpreis wirklich schützt, braucht es drei Dinge schriftlich, und genau diese gehören in ein sauberes Lastenheft und Pflichtenheft: eine präzise Leistungsbeschreibung, messbare Abnahmekriterien und eine Liste der Ausschlüsse. Fehlt einer der drei Punkte, ist der Festpreis eine Schätzung mit Streitpotenzial.

Aufwand: ehrlich bei Unsicherheit, aber nur mit Leitplanken

Bei der Abrechnung nach Aufwand, international Time and Material genannt, bezahlt der Auftraggeber die geleistete Zeit zu einem vereinbarten Satz. Das Modell ist ehrlich, wenn niemand den genauen Umfang kennen kann, etwa bei der Weiterentwicklung eines Produkts, das schon im Markt ist, oder bei einer neuen Idee, die sich während der Arbeit verändert.

Der Nachteil liegt auf der Hand: Das Kostenrisiko trägt der Auftraggeber. Damit das beherrschbar bleibt, gehören diese Leitplanken in jede Aufwand-Vereinbarung:

• Kostendach pro Phase oder Monat, bei dessen Erreichen gestoppt und neu entschieden wird.
• Kurze Abschnitte mit sichtbarem Ergebnis, zum Beispiel alle zwei Wochen eine Demo von funktionierender Software, nicht nur ein Statusbericht.
• Priorisierte Liste der Anforderungen, die der Auftraggeber führt. Gebaut wird von oben nach unten, und wenn das Budget endet, fehlt das Unwichtigste.
• Transparente Zeiterfassung pro Aufgabe, nicht nur eine Monatssumme.

Genau hier setzt agile Softwareentwicklung an. Scrum organisiert die Arbeit in kurzen, festen Zyklen mit einer Vorführung am Ende, Kanban in einem stetigen Fluss mit begrenzter paralleler Arbeit. Beide machen Zwischenstände regelmässig sichtbar. Das macht Aufwand-Abrechnung kontrollierbar, weil man jederzeit sieht, wofür das Geld ausgegeben wurde, und umsteuern kann.

Wasserfall oder agil: was zur Aufgabe passt

Das Wasserfall-Modell hat einen schlechten Ruf, oft zu Unrecht. Es passt gut, wenn die Anforderungen wirklich feststehen und sich während des Projekts nicht ändern: bei regulatorischen Vorgaben, bei der Ablösung eines bekannten Systems oder bei Schnittstellen mit festen Spezifikationen. Dort ist eine saubere Planung vorab effizienter als ständiges Nachsteuern.

Agile Arbeitsweisen spielen ihre Stärke aus, wenn man unterwegs lernt: bei neuen Produkten, bei Software für Nutzer, deren Verhalten man noch nicht kennt, und überall dort, wo erst die Benutzung zeigt, was wirklich gebraucht wird. In der Praxis arbeiten viele Projekte hybrid: Eine kurze, gründliche Discovery-Phase klärt Ziel, Nutzer und Rahmen, danach wird in kurzen Zyklen gebaut.

Der Mittelweg: fixer MVP-Umfang

Für neue digitale Produkte hat sich ein drittes Modell bewährt, das die Vorteile beider Seiten kombiniert. Statt das ganze Produkt zum Festpreis zu beauftragen oder ein offenes Aufwandsprojekt zu starten, wird ein klar begrenzter erster Schritt zu einem festen Betrag umgesetzt: ein einziger Anwendungsfall, vollständig und mit echten Nutzern testbar, alles andere ausdrücklich ausgeschlossen.

Das ist die Idee hinter dem Minimum Viable Product. Das Budget ist fix, das Risiko begrenzt, und am Ende steht nicht nur Software, sondern eine Erkenntnis: Wird das Produkt genutzt und bezahlt? Erst dann wird entschieden, ob und wie weitergebaut wird, und dann mit deutlich besserem Wissen über den richtigen Umfang.

Bei DLM Digital beginnt ein solcher Prototyp oder MVP ab CHF 10'000. Er deckt einen Anwendungsfall ab, mit echten Daten, echten Nutzern, einer angebundenen Zahlung, wenn die Zahlungsbereitschaft geprüft werden soll, und Messaufbau. Websites liegen bei uns je nach Umfang zwischen CHF 3'000 und 25'000. Was darüber hinaus bei grösseren Softwareprojekten anfällt und warum Offerten so weit auseinanderliegen, erklärt unsere Seite Software-Kosten Schweiz.

Fallen in Software-Offerten

Unabhängig vom Modell tauchen in Offerten immer wieder dieselben Probleme auf. Eine Checkliste für den Vergleich:

1. «Inklusive Anpassungen» ohne Zahl. Wie viele Korrekturrunden, wie viele Stunden? Ohne Zahl ist das ein Versprechen ohne Inhalt.
2. Keine Abnahmekriterien. Wann ist eine Funktion «fertig»? Wenn das nicht messbar ist, wird darüber gestritten.
3. Betrieb und Wartung fehlen. Hosting, Updates, Backups und Support kosten laufend Geld. Eine Offerte ohne diesen Teil ist nicht vergleichbar mit einer, die ihn enthält. Was ein Wartungsvertrag regeln sollte, steht in Service Level Agreement für Software.
4. Unklare Rechte am Code. Wem gehören Quellcode, Daten und Konten nach Projektende? Fehlt das, droht Vendor-Lock-in.
5. Agil auf dem Papier, Festpreis im Vertrag. Wenn «agile Umsetzung» versprochen wird, der Vertrag aber jede Änderung als kostenpflichtigen Nachtrag behandelt, ist die Agilität nur ein Wort.
6. Schnittstellen als Nebensatz. «Anbindung an die Buchhaltung» kann eine Stunde oder drei Wochen sein. Welche Daten, in welche Richtung, mit welcher Fehlerbehandlung?
7. Keine Zwischenstände. Wer erst am Ende etwas sieht, merkt zu spät, wenn das Projekt in die falsche Richtung läuft.

Zwei Offerten vergleichbar machen

Zwei Offerten für «dasselbe» Projekt können weit auseinanderliegen, und beide können seriös sein, wenn sie unterschiedliche Annahmen treffen. Um sie vergleichbar zu machen, hilft ein einfaches Vorgehen:

• Annahmen nebeneinanderlegen. Was setzt jeder Anbieter voraus, was schliesst er aus?
• Den gleichen Umfang abfragen. Eine kurze, eigene Liste der fünf wichtigsten Funktionen an alle Anbieter schicken und um Preis pro Punkt bitten.
• Nach dem ersten Schritt fragen. Was würde der Anbieter als Erstes bauen, und was kostet dieser Schritt allein? Die Antwort zeigt, wie er über Risiko denkt.
• Gesamtkosten über mehrere Jahre rechnen. Entwicklung plus Betrieb plus Weiterentwicklung. Der Begriff dafür ist Total Cost of Ownership.

Ein Beispiel aus der Praxis

Bei der Betriebssoftware für Karo Kanaltechnik hängen Offerten, Aufträge, Einsatzplanung, Monteur-Rapporte, QR-Rechnungen mit Mahnwesen und ein Kundenportal direkt zusammen. Ein solches System lässt sich kaum vollständig in einem Pflichtenheft beschreiben, bevor die erste Zeile Code existiert, und es ist mit dem ersten Livegang auch nicht abgeschlossen: Eine iOS-App für unterwegs ist bei Karo zum Beispiel noch in Arbeit. Für Software, die tägliche Arbeit abbilden soll, ist deshalb die Frage entscheidend, wie Erweiterungen nach dem ersten Schritt beauftragt werden. Ein Festpreis auf den ersten Umfang und eine klare Regel für alles Weitere, etwa Aufwand mit Kostendach, ist dafür meist realistischer als ein einziger Festpreis auf ein Gesamtpaket.

Fazit

Festpreis, Aufwand und fixer MVP-Umfang sind keine Glaubensfragen, sondern Werkzeuge für unterschiedliche Situationen. Ist der Umfang klar, schützt ein gut beschriebener Festpreis. Ist er unsicher, ist Aufwand mit Kostendach und kurzen Zyklen ehrlicher. Und bei neuen Produkten ist ein fest begrenzter erster Schritt meist die beste Wahl, weil er das Risiko klein hält und die Grundlage für jede weitere Entscheidung liefert. Wer zusätzlich Ausschlüsse, Abnahme, Betrieb und Rechte am Code prüft, vermeidet die meisten Konflikte, bevor sie entstehen. Wer vor der Frage steht, ob überhaupt selbst gebaut werden soll, findet die Grundlagen unter Individualsoftware Schweiz.