Honorar für Softwareentwickler: Festpreise sind nicht immer sinnvoll!

Die Entwicklung individueller, unternehmensinterner Software ist ein sehr komplexer Vorgang, bei dem es darum geht, unternehmensinterne Abläufe maßgeschneidert dem Unternehmen und seinen Strukturen anzupassen. Es handelt sich dabei gerade nicht um Standardsoftware.

Einer Entwicklung geht eine intensive Analyse der jeweiligen Wünsche voraus. Diese Analyse wird entweder unternehmensintern vorgenommen und definiert und/oder in Zusammenarbeit mit (externen) Entwicklern vorgenommen. Je nach Umfang kann allein dieser Vorgang einige Tage oder Wochen oder auch Monate beanspruchen. Sofern ein externer Entwickler mit diesem Thema betraut oder beratend hinzugezogen wird, muss ein Vertrauensverhältnis vorliegen oder sich entwickeln.

Wer einmal schlechte Erfahrungen mit externen Entwicklern gemacht hat, wird zukünftig vorsichtig sein. Zu den schlechten Erfahrungen gehört nebst sich im Verlaufe der Entwicklung herausstellender

• nicht-ausreichender Kompetenz

• oder terminlicher Unzuverlässigkeit,

• gewiss auch eine nicht hinreichende Reaktionszeit (Mails werden spät beantwortet)

• oder ein „Entgleiten“ des Kostenrahmens bzw. eine nennenswerte Abweichung vom ursprünglichen Angebot.

Festpreise? Nicht immer sinnvoll!

Bei Verhandlungen macht man gelegentlich die Erfahrung, dass Auftraggeber gerne einen Festpreis sehen würden, um den Kostenrahmen kalkulieren zu können (für Software-Projekte wird häufig ein bestimmter Budget-Rahmen festgelegt).

So verständlich der Wunsch nach einem genau kalkulierbaren Umfang auch ist, so ergibt sich daraus in manchen Fällen ein Problem. Selbstverständlich muss bei der Entwicklung ein Angebot vorliegen zu dem auch ein Kostenrahmen gehört. Wenn aber ein Festpreis Bestandteil eines Auftrages ist, muss auch die Umsetzung, also „was genau zum Pflichtenheft gehört“ definiert werden.

Der Erfahrung nach ist es allerdings kaum möglich, dieses Pflichtenheft wirklich auf den letzten Punkt genau zu definieren. Dazu würde

• jede Abfrage,
• jedes Formular,
• jeder Printout,
• jede Bestimmung von verwendeten Farben, Formen, Nutzern und
• sonstigen (auch technischen) Modalitäten &  Spezifikationen

gehören. Da das im Vorfeld eben nicht ganz exakt bestimmt werden kann, führt das zu einem Problem, dem man im Umfeld der Entwicklung gelegentlich begegnet.

Zeitverlust durch Nachverhandlungen vermeiden!

So wurde kürzlich ein Fall bekannt, bei dem zur Entwicklung eines neuen Online-Auftritts eines mittelständischen Unternehmens mit einem Website-Entwicker-Büro ein Festpreis ausgehandelt wurde und ein Pflichtenheft angelegt wurde.

Der beauftragte Betreuer und Tester des mittelständischen Unternehmens war nicht hinreichend über die Vertragsmodalitäten informiert.

Er scheiterte mit seinen Verbesserungsvorschlägen und Korrekturen, die er bei dem Web-Entwickler anbrachte ständig an der Formulierung „dieses sei aber nicht Bestandteil des Vertrages… „, der Punkt wurde als „Zusatz“ aufgeführt. Jeder dieser „Zusatzpunkte“ wird dann separat nachverhandelt, was die Realisierung verzögert.

Zum Abschluss (Projekt-Abnahme) eines derartigen Projektes werden die einzelnen Punkte des Pflichtenheftes gesichtet und bewertet. Hierbei kommt es dann durchaus zu Missverständnissen über die Umsetzung, die während der Entwicklung ggf. nicht ständig abgestimmt wurde.

Zwar kann der Entwickler dann zu Recht darauf verweisen, dass sich alle Punkte in der Software wiederfinden, aber der Auftraggeber entgegnet mitunter „das habe ich mir aber anders vorgestellt“ oder „warum kann die Datenbank das denn nicht, die Daten sind doch da“.

Spätestens an dieser Stelle wird es für alle Beteiligten unerfreulich. Die Daten sind zwar „da“, aber die Auswertung, die der Auftraggeber jetzt gerne sehen würde, wurde bei der Definition vermutlich nie benannt.

Alle Punkte sind nachweislich umgesetzt, aber irgendwie stellt sich die Usability nicht so dar, wie es sich der Auftraggeber gewünscht hat. Der Auftraggeber verlangt Nachbesserung, der Entwickler sieht diese Anpassungen als Zusatzpunkt.

Transparenz bei der Entwicklung ist gefragt!

Die Entwicklung einer unternehmensinternen Software sollte als ein Prozess(!) betrachtet werden, der fortlaufend genau abgestimmt und getestet werden muss und der sich im Verlaufe der Entstehung entwickelt! Während des Prozesses sollte von allen Seiten Transparenz vorliegen und keinerlei Versteckspielchen vorgenommen werden, das betrifft auch den Kostenrahmen.

Wenn bei einem Angebot ein Aufwand angegeben wird, ist das eine „vorläufige Einschätzung„, die sich an den im Angebot benannten Umsetzungspunkten orientiert.

Bei Zwischenständen sollte unbedingt jeweils eine „Wasserstandsmeldung“ vorgenommen werden (bisher „verbrauchter Aufwand“), so dass der Auftraggeber stets im Bilde ist und ggf. zeitnah reagieren kann.

Sofern inhaltlich Unstimmigkeiten vorliegen, sollten diese schnellstens geklärt werden. Dazu gehört auch, dass vorab Reaktions-Zeiten ausgemacht werden.

Beispiel: Während der Entwicklung ergibt sich die Frage nach einer anzupassenden Datenstruktur. Erst wenn diese Frage geklärt ist, kann die Entwicklung sinnvoll weitergeführt werden. Häufig wird dann etwa seitens der Entwickler „vermutet“ und auf Basis dieser Annahme einfach weiterentwickelt, ggf. mit der Folge, dass später aufwändige Anpassungen vorgenommen werden müssen (für beide Seiten sehr ärgerlich).

Alternativ kann die Beantwortung dieser wichtigen Frage seitens des Auftraggebers derart verzögert werden, dass der Fertigstellungstermin in Frage gestellt werden muss, was aber dem Entwickler nicht als Verschuldung angelastet werden kann, aber manchmal doch wird.

Begriff „Entwicklung“ – wörtlich nehmen!

Der Begriff „Entwicklung“ sollte wörtlich genommen werden. Ein „Fest-Preis“ steht diesem Prozess im Einzelfall eher im Wege, alternativ sollte ein Rahmen vereinbart werden, ggf. mit einer Angabe, um welchen Wert dieser max. abweichen darf. Diese Abweichung muss allerdings für den Auftraggeber genau nachvollziehbar und möglichst rechtzeitig erkennbar sein.