Der Einfluss von Vergütungsmodellen auf das Preis-Leistungs-Verhältnis von Entwicklungsdienstleistungen

Wie du sicher stellst, dass du von deinem Entwicklungsdienstleister den maximalen Wert für dein Geld bekommst.

Wenn Softwareentwicklung nicht zu deinen Kernkompetenzen gehört, du das Aufbauen eines eigenen Entwicklungsteams als kostspieliges und riskantes Unterfangen einschätzt oder du auf dem Arbeitsmarkt nur mit viel Mühe qualifizierte Softwareingenieure findest, wirst du das Beauftragen eines externen Entwicklungsdienstleister für dein Softwareprojekt in Betracht ziehen. Externe Dienstleister bauen dir neue Softwareapplikationen von Grund auf, helfen dir beim Modernisieren von existierenden Applikationen, erhöhen die Effizienz deiner DevOps Prozesse oder verstärken deine bestehende Entwicklungsorganisation mit zusätzlicher Manpower.

Solltest du dich dazu entscheiden, mit einem externen Dienstleister zusammenzuarbeiten, musst du dich als Auftraggeber mit dem potentiellen Auftragnehmer auf ein Vergütungsmodell einigen. Das Vergütungsmodell und der damit verbundene Vertrag legen fest, was dir der Auftragnehmer zu welchem Preis liefert. Das scheint auf den ersten Blick eine triviale Herausforderung zu sein. Doch wer bereits in IT- oder Entwicklungsprojekte involviert war, weiss das dies keine einfache Problemstellung ist. In der Praxis können die Kosten explodieren oder die Qualität des Ergebnisses lässt zu wünschen übrig. Dies wiederum führt zu Uneinigkeit zwischen Auftraggeber und Auftragnehmer bezüglich der Vergütung der Leistung.

Die Wahl des Vergütungsmodelles und die Konditionen haben einen direkten Einfluss auf die Wirtschaftlichkeit und die Erfolgsaussichten deines Softwareprojektes. Als Auftraggeber möchtest du höchstwahrscheinlich möglichst hohe Qualität zu minimalen Gesamtkosten, also ein möglichst gutes Preis-Leistungs-Verhältnis. Für Entwicklungs- und Ingenieurdienstleistungen heisst das konkret, dass du als Auftraggeber sicherstellen musst, dass der Auftragnehmer die erwarteten Resultate in bestmöglicher Qualität liefern kann und er dir dafür einen möglichst guten und fairen Preis machen kann.

In diesem Artikel vergleichen wir verschiedene Vergütungsmodelle und zeigen auf, welchen Einfluss diese Modelle auf das Preis-Leistungs-Verhältnis und die Gesamtbetriebskosten eines Softwareprojektes haben. Wir vergleichen die beiden etablierten Vergütungsmodelle

• Vergütung zu einem Festpreis mit
• Vergütung nach Aufwand.

Ausserdem schlagen wir ein drittes Vergütungsmodell vor, welches auf der agilen Softwareentwicklung beruht, die Vorteile der beiden etablierten Vergütungsmodelle vereint und deren Nachteile überwindet:

• Ein Sprint-basiertes Vergütungsmodell

Vergütung zu einem Festpreis vermittelt eine trügerische Kostensicherheit

Die Entwicklung einer Softwarelösung zu einem Fixpreis einzukaufen, scheint zwar aus Auftraggebersicht naheliegend, weil man sich eine vermeintliche Kostensicherheit und ein garantiertes Resultat verspricht. In der Praxis ist dies jedoch illusorisch. Die Vergütung zu einem Fixpreis wird nach Schweizer Recht in einem sogenannten Werkvertrag abgebildet (Art. 363 ff. OR). Der Auftraggeber beschreibt detailliert, was vom Auftragnehmer geliefert werden soll (juristisch “das Werk”). Der Auftragnehmer nennt den fixen Preis, zu dem er die Software liefern kann. Die Praxis zeigt, dass es nicht möglich ist, alle Anforderungen an eine Softwarelösung im Voraus genau genug zu spezifizieren. In der Regel werden wichtige Funktionsanforderungen vergessen oder Rahmenbedingungen und Nutzerbedürfnisse ändern sich während des Projektes. Uneinigkeiten über die Kompensation von geänderten oder neuen Anforderungen zwischen Auftraggeber und Auftragnehmer sind also vorprogrammiert.

Mit einem Fixpreis-Kompensationsmodell bezahlt der Auftraggeber tendenziell einen zu hohen Fixpreis und sollte mit zusätzlichen Ausgaben im Projektverlauf rechnen. Weil es für den Auftragnehmer extrem schwierig ist, den Gesamtaufwand eines Entwicklungsprojektes genau abzuschätzen, rechnet der Auftragnehmer eine gewisse Sicherheitsmarge ein. D.h. der Auftraggeber bezahlt nicht nur für die Entwicklungsdienstleistung, sondern noch ein Extra für das Risiko einer falschen Aufwandsschätzung. Zusätzlich bezahlt der Auftraggeber ungeplante Kosten für nicht spezifizierte oder neue Anforderungen, welche im Verlauf des Projektes dazu kommen. In der Regel sind sogenannte “Change Requests” nicht im Fixpreis inkludiert und werden zusätzlich in Rechnung gestellt.

Vergütung nach Aufwand macht aus einem Entwicklungsprojekt ein Fass ohne Boden

Kauft der Auftraggeber Softwareentwicklung nach Aufwand ein, hat er zwar maximale Flexibilität bezüglich Entwicklungsumfang, aber kaum Chancen, die Gesamtkosten abzuschätzen. Die Vergütung nach Aufwand wird im Schweizer Recht mit dem Begriff Auftrag definiert (Art. 394 ff. OR) und in Form eines Dienstleistungsvertrag abgebildet. Dabei schuldet der Auftragnehmer dem Auftraggeber lediglich ein Tätigwerden nach anwendbaren Sorgfaltspflichten und bestem Wissen und Gewissen. Der Auftraggeber bezahlt für geleistete Zeit (z.B. Stunden oder Tage) und verbrauchtes Material. Der Auftragnehmer macht in der Regel zwar eine Schätzung, wie viel Zeit er für die Entwicklung einer Softwarelösung benötigt, ist aber nicht verpflichtet, diese Schätzung auch einzuhalten.

Mit einem auf Aufwand basierten Kompensationsmodell bezahlt der Auftraggeber die Ineffizienz der Entwickler und trägt dazu noch das gesamte Erfolgsrisiko. Gerade bei Softwareentwicklern variiert die Produktivität enorm. Eine Vielzahl von Studien seit den 60er Jahren proklamieren den “10x” Faktor in der Produktivität von Programmierern—also einen 10-fachen Unterschied, was ein Entwickler in einer gewissen Zeiteinheit leisten kann. Ob bei einer bezahlten Stunde Arbeit auch effektiv verwertbare Resultate entstehen, ist also nicht garantiert. Ausserdem setzt Vergütung nach Aufwand falsche Anreize für den Auftragnehmer. Wenn er für die Erfüllung einer Aufgabe länger braucht, kann er mehr verrechnen. Im Härtefall kann der Auftragnehmer nach der geleisteten Zeit auf Vergütung bestehen, ohne irgendetwas erreicht zu haben. Der Auftraggeber trägt das Erfolgsrisiko also vollumfänglich.

Ein Sprint-basiertes Vergütungsmodell reduziert das Projektrisiko und ermöglicht trotzdem Flexibilität

Bei einem Sprint-basierten Vergütungsmodell bezahlt der Auftraggeber einen vor dem Projekt fix definierten Preis pro Sprint. In der agilen Softwareentwicklung ist ein Sprint eine fixe Zeitperiode—von in der Regel zwei Wochen—in welcher bestimmte Arbeitsergebnisse erreicht werden müssen. Auftraggeber und Auftragnehmer definieren die Arbeitsergebnisse und deren Abnahmekriterien gemeinsam vor jedem Sprint. Der Auftragnehmer garantiert die Erfüllung der definierten Ergebnisse pro Sprint. Bei Nicht- oder Teilerfüllung bezahlt der Auftraggeber den Sprint nicht oder nur teilweise.

Das finanzielle Risiko ist sowohl für den Auftraggeber als auch für den Auftragnehmer überschaubar. Der Auftraggeber hat eine Garantie, dass er für sein Geld mess- und greifbare Resultate bekommt und nicht nur Arbeitsstunden bezahlt, die zu nichts führen. Beide, Auftraggeber und Auftragnehmer können die Arbeitsergebnisse und deren Abnahmekriterien für den Zeithorizont von einem Sprint genügend präzise definieren. Der Auftragnehmer kann zuverlässig abschätzen, welche Resultate er innerhalb der kommenden zwei Wochen realistischerweise erreichen kann und kann diese mit gutem Gewissen und ohne unnötige Sicherheitsmargen versprechen. Für den Auftragnehmer ist das finanzielle Risiko, wenn er sich verschätzt und die versprochenen Arbeitsergebnisse nicht liefern kann, auf den Preis des Sprints begrenzt.

Der Auftraggeber behält beim Sprint-basierten Vergütungsmodell die Flexibilität, den Entwicklungskurs zu korrigieren, sollte sich herausstellen, dass sich die anfänglich definierten Anforderungen geändert haben. Wie auch bei der Vergütung nach Aufwand können die Entwicklungsaktivitäten priorisiert werden, von welchen man sich den höchsten Mehrwert verspricht. Allerdings wird das Preis-Leistungs-Verhältnis deutlich sichtbarer, weil dem fixen Preis pro Sprint greifbare Arbeitsergebnisse gegenübergestellt werden können. Zudem ändert das Mindset des Auftragnehmers von “Stunden leisten” zu “Resultate liefern”.

Ebenso wichtig wie das Vergütungsmodell ist eine vertrauensvolle Beziehung zwischen Auftraggeber und Auftragnehmer.

Agile Entwicklung und ein Sprint-basiertes Vergütungsmodell helfen, das Risiko in Entwicklungs- und Innovationsprojekten zu reduzieren. Allerdings sind und bleiben Entwicklungs- und Innovationsprojekte von Unsicherheit geprägt. Daran ändert auch ein Sprint-basiertes Vergütungsmodell nichts. Garantien für den Projekterfolg gibt es nicht, auch wenn dies von Managern mit Fragen wie “Wie lange dauert es und was kostet es insgesamt?” oft gewünscht wird. Anstatt langfristige Pläne und Budgets zu erstellen, die dann doch wieder verworfen werden, sollten wir darauf fokussieren, mit einem fixen Budget—dem fixen Preis pro Sprint—jeweils den maximalen Mehrwert zu generieren. Und genau das wird mit einem Sprint-basierten Vergütungsmodell erreicht.

Das richtige Vergütungsmodell und das entsprechende Vertragswerk, welches ein solches abbildet, unterstützen eine funktionierende Zusammenarbeit zwischen Auftraggeber und Auftragnehmer. Ebenso wichtig sind allerdings eine Geschäftsbeziehung, die auf Vertrauen und einer gemeinsamen Vision basiert. Denn das ist es schlussendlich, was alle Beteiligten dazu motiviert, brauchbare, wertsteigernde und von den Nutzern geliebte Softwarelösungen zu entwickeln und zu betreiben.

Bei EMBRIO.tech haben wir das Sprint-basierte Vergütungsmodell in die Praxis umgesetzt und ein darauf zugeschnittenes Vertragswerk geschaffen, das ein maximales Preis-Leistungs-Verhältnis garantieren und Transparenz und Vertrauen fördern soll. Dabei haben wir darauf geachtet, dass das Vertragswerk fair für beide Parteien ist, mit geltendem Schweizer Recht kompatibel ist und den administrativen Aufwand während dem Projekt nicht erhöht, sodass wir uns auf das Wesentliche konzentrieren können—überzeugende Softwarelösungen zu schaffen.