Abrechnungsmodelle in Softwareprojekten
Es gibt unterschiedlichste Möglichkeiten ein Softwareprojekt abzurechnen.
Im Beitrag die gängigsten Abrechnungsmodelle und wann was sinnvoll ist.
Einführung
Software zu erstellen ist meistens eine komplexe Angelegenheit. In den meisten Fällen arbeiten einer oder mehrere Entwickler für Wochen und Monate an der Fertigstellung.
Hier ergibt sich bereits die erste Herausforderung: Kann man diese Arbeiten, welche über diese Wochen und Monate und über unterschiedlichste Entwickler, Projektmanagement-Stufen (Teamleiter, Projektmanager), Tester, Designer laufen, genau bestimmen?
Die Antwort muss, wenn man ehrlich mit sich ist, “Nein” heissen. Es ist fast unmöglich zu wissen, wie die Anforderungen genau aussehen werden.
Besonders auch weil – sich die Anforderungen auch während des Projektes ändern – und nicht nur in der Phase vor dem Projektstart.
Da fast jeder IT Dienstleister und jede Agentur weiss, dass der Endkunde (nicht alle, aber einige) hierfür kein Verständnis haben werden, gibt es immer noch Abrechnungsmodelle wie den Festpreis. Dieser kann sogar in einigen Fällen interessant sein. Besonders dann, wenn die Anforderungen tatsächlich von Anfang an relativ, bis sehr gut einschätzbar sind.
Der beste Weg, um wirklich erfolgreich zu sein, wird jedoch die “Abrechnung nach Aufwand” sein. Hier werden jeweils die Stunden abgerechnet, welche auch tatsächlich anfallen (so funktioniert die Welt normalerweise. Das beste Beispiel ist ein festangestellter Arbeitnehmer. Diesem kann man auch nicht sagen: “Wir haben einer einen Fixpreis für diesen Monat von 100 Stunden ausgemacht. Die restlichen 60 Stunden musst Du selber schauen wo Du die herbekommst”.) In der Realität muss komplett bezahlt werden und nicht teilweise.
Hier nun die gängigsten Methoden der Abrechnung.
Festpreis
Es ist fraglich ob der Festpreis eine gute Methode ist Preise zu erstellen. Besonders Dienstleister mögen diese Art der Bezahlung nicht.
Zu oft werden in der Angebotsphase vom Dienstleister wichtige Punkte übersehen. Oder es wird vom Auftraggeber übersehen, ein wichtiges Detail zu erwähnen. Oder gar beide schätzen das Projekt falsch ein.
Der Softwarehersteller könnte nun folgendes machen: Der Aufwand (in Kosten) plus zwanzig Prozent Aufschlag (welcher als Gewinn dienen soll).
Die Problematik hier ist jedoch: Was wenn etwas übersehen wurde und der Kunde sagt “Das war aber Teil des Projektes”. Dann sind diese 20 Prozent Aufschlag sehr schnell verzehrt und höchstwahrscheinlich könnte es noch ein Minusgeschäft geben.
Also sieht die Lösung dann so aus, dass man zirka 40 bis 50 Prozent oder mehr auf Festpreise draufschlägt, nur um sicherzustellen, dass man in der Gewinnzone steht. (Am Ende handelt es sich bei einem IT Unternehmen ja auch nicht um ein gemeinnütziges Unternehmen, sondern zahlt in den meisten Fällen gute Gehälter und muss dementsprechend auch haushalten)
Aus einer “Fairness” Sicht ist dieser Ansatz nicht der Beste. Denn beide Seiten (Dienstleister und Auftraggeber) werden sich ein hin und her bieten. Der Auftraggeber wird so gut wie möglich versuchen, noch eine kleine Schippe an Aufgaben mehr draufzupacken, welches natürlich Teil des Projektes gewesen sein soll. Und der Softwaredienstleister wird so gut wie möglich alle zusätzlichen Aufgaben von sich weisen.
Das Hauptproblem hierbei: Das eigentliche Ziel, nämlich das erfolgreiche Softwareprojekt, dass den Kunden zu mehr Produktivität, mehr Umsatz, weniger Kosten, etc. führt, verschiebt sich in den Hintergrund.
Das Gerangel, um ein “Schnäppchen” auf Seiten des Auftraggebers und der “Gewinnmarge” auf Seiten des IT Dienstleisters gewinnen überhand.
Ein Festpreis muss nicht immer etwas schlechtes sein. Es gibt einige Fälle in denen solch ein Vorgehen gut sein kann. Hier einige davon:
1) Der Aufwand kann gut eingeschätzt werden
Der Kunde und auch der Auftragnehmer sind sich genau bewusst, was umgesetzt werden soll. Eine Website mit 15 Unterseiten, einem Kontaktformular und einer Landing Page wäre so ein Beispiel. Wenn die Wireframes (oder grobe Skizzen) erstellt sind, kann man den Aufwand relativ gut bestimmen.
2) Bei kleinen Aufträgen
Auch bei kleineren Aufträgen macht es Sinn. Ein Beispiel, ausserhalb von Softwareprojekten, wäre eine Flyer-Erstellung. Der Aufwand ist bekannt und der Festpreis als Abrechnungsmodell kann genutzt werden.
3) Wenn der Auftraggeber flexibel ist, welche Leistungen erbracht werden
Natürlich muss nicht nur der Auftraggeber flexibel sein, sondern auch der Dienstleister muss bereit sein, seinen maximalen Output für das geleistete Entgelt zu erbringen.
Der Festpreis kann also seine Vorteile und Nachteile haben. Besonders bei gut umschreibbaren Aufgaben ist das der richtige Ansatz.
Softwareprojekte sind jedoch oftmals nicht so gut umschreibbar. Daher ist das Folgende eines der besseren Abrechnungsmodelle: Abrechnung nach Aufwand. Besonders für Unternehmen, für welches die Erreichung der Firmenziele im Vordergrund stehen.
Bezahlung nach Aufwand
Hierbei berechnet der Dienstleister dem Kunden einfach die Stunden die angefallen sind. Das ist eigentlich ziemlich einfach.
Ein Designer arbeite in den letzten 30 Tagen, für 28 Stunden am Design. Ein Junior Webentwickler arbeitete an der Lösung für 127 Stunden, ein Projektmanager hat 20 Stunden benötigt und der Tester hat 25 Stunden daran getestet.
Nun werden die jeweiligen Stundensätze mit den Stunden multipliziert und man hat den Rechnungsbetrag für den Kunden für den jeweiligen Monat. Sehr simpel.
Hierfür müsste dann entweder ein hohes Vertrauen auf Seiten des Kunden vorhanden sein oder ein sehr genau gehaltenes Projektmanagement-Werkzeug, in welchem die Mitarbeiter (auf Seiten des Dienstleisters) alle Zeiträume, am besten Minutengenau eintragen kann.
Warum ist gerade dieses Zahlungsmodell am besten? -> Der Grund ist eigentlich ganz simpel. Es hätte einen erfahrenen Softwareentwickler, mit zehn bis zwanzig Jahren benötigt, um den genauen Aufwand, im Vorfeld, des 30 Tage Zeitraums, zu bestimmen. Dieser müsste jedoch fast ein Genie sein, um im Vorfeld genau bestimmen zu können, dass die Designerin 28 Stunden braucht, der Junior Entwickler 127 Stunden und der Projektmanager 20 Stunden und dann noch der Aufwand des Testers. Fast unmöglich, auch für einen Top Experten.
Im Nachhinein könnte jedoch auch ein Praktikant die Stunden zusammenzählen. (Eine weitere Besonderheit in der Softwareentwicklung. Man kann denn Eisenhart schweren Weg gehen, oder den simplen. Hierfür braucht es dann jeweils nur Verständnis für das Gegenüber.)
Unternehmensabrechnung
Nun gibt es riesengrosse Konzerne, mit grossen Rechtsabteilungen und vielen Managern.
Hier haben sich noch viele weitere Abrechnungsmodelle etabliert.
Darunter die folgenden:
- Time & Material (soetwas ähnliches wie die Abrechnung nach Aufwand)
- Agile Pricing: Hier wird meistens nach sogenannten Sprints abgerechnet. Diese Sprints dauern im Schnitt eine Woche bis vier Wochen.
- Komplexe Pricing Modelle: Es gibt komplexere Preismodelle, wie zum Beispiel “adVANTAGE: A fair pricing model for agile software development contracting” das aus einem Buch für agile Softwareentwicklung hervorgeht.
Besonders die komplexeren Abrechnungsmodelle sollen eine Verteilung des Risiko’s auf den Dienstleister und den Auftraggeber gleichermassen ermöglichen.
Im Grund genommen werden jedoch meistens keine grossen Gewinneinsparungen erzielt. Es geht meistens um Beschäftigungstheorie. Die Einkäufer, Projektleiter, Teamleiter, etc. müssen auch etwas zu tun haben. Und so ein komplexes Abrechnungsmodell, wirkt beruhigend für so manchen Manager 😊
Fazit
Wenn man ein festes Budget hat, dann sollte man ehrlich und fair seine Anforderungen darlegen. Falls der Dienstleister zustimmen sollte, dann sollte man diesen jedoch auch nicht festnageln, a la “Aber das gehört zu so einem Projekt dazu”, “Das sollte aber klar sein” undsoweiterundsofort.
Jeder sollte seinen Vorteil aus dem Projekt ziehen. Der Dienstleister soll eine akzeptable Marge erhalten und der Auftraggeber eine Dienstleistung, welche mehr einbringt (an Effizienzsteigerung, Kostenersparnis, etc.) als sie kostet.
Bei komplexen Softwareprojekten kann jedoch nur das Abrechnungsmodell nach Aufwand der Richtige sein.
Um den Aufwand nicht in das unendliche steigen zu lassen, kann man auch die 20 wichtigsten Funktionalitäten auflisten und diese priorisieren. Wenn man sieht dass das Budget nicht mehr ausreicht, dann kann man die Punkte mit kleiner Priorität, aus der Liste streichen. Oftmals sind nur die 3 bis 5 wichtigsten Funktionalitäten wichtig für den Projekterfolg.
Interessante Beiträge:
Klaus Breyer schreibt zu Abrechnungsarten in agilen IT Projekten
Vorteile der Aufwands-Berechnung
Bilder: Canva
Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.
Schreibe einen Kommentar