Kalkulation eines Festpreises für ein neues Programm

[mjustin]

Im Bereich der Agilen Softwareentwicklung wurde das Thema Aufwand / Festpreis in den letzten Jahren diskutiert und mögliche Vertragsgestaltungen in Artikeln wie "Der agile Festpreis" gut dargestellt:

http://it-republik.de/jaxenter/artik...reis-3232.html

Neben Aufwand und Festpreis werden auch alternative Vertragsformen vorgeschlagen, z.B.:

Zitat:

"Bei Proviant und Prämie zahlt der Auftraggeber beispielsweise einen gerade mal kostendeckenden Tagessatz nach Aufwand. Wenn ein vorher festgelegtes Ziel erreicht wird, erhält der Auftragnehmer eine Prämie, die dann letztlich seinen Gewinn definiert. "

[haentschman]

So etwas ähnliches wollte ich auch grad vorschlagen...

Sinngemäß:
Lieber kleinere Brötchen mit dem Stundensatz aber dafür bis zum Ende durchgehend als freier Mitarbeiter. Vieleicht sogar Festeinstellung für den Zeitraum des Projektes. Viele Varianten sind möglich. Dem Auftraggeber ist jedenfalls nicht geholfen wenn du nach 80% Fertigstellung in Konkurs gehst weil du im Angebot einen Posten vergessen hast.

[Gustav.R]

Und bei einem Festpreis auch daran denken, daß jemand die 19% Umsatzsteuer bezahlen muß :?

[p80286]

Zitat:

Zitat von Gustav.R (Beitrag 1112895)

Und bei einem Festpreis auch daran denken, daß jemand die 19% Umsatzsteuer bezahlen muß :?

????
Für Gewerbetreibende ist das ein durchlaufender Posten, was soll da extra beachtet werden?

Gruß
K-H

[Jacques Murell]

Aufwandsschätzung bei Softwareprojekten könnte da vielleicht auch Dir recht hilfreich sein. ;)

[WInfo]

Zitat:

Zitat von RWarnecke (Beitrag 1112882)

Ich war bis jetzt immer davon ausgegangen, dass das Lastenheft im Grunde das Projekt beschreibt mit den Zielen und das Pflichtenheft wie Du schon gesagt hast den Liefergegenstand beschreibt.

Nicht ganz. Die Pflichten (Pflichtenheft), beschreiben, was umgesetzt werden soll, und sind mehr oder weniger verbindlich (also diskutierbar). Diese werden dann bei Vertragsabschluss, zur Last (Lastenheft), also Vertragsbestandteil.

An Schätzverfahren, gibt es mehr als genug. Manche wiegen einfach das Pflichtenheft und geben einen Kilo-Preis ab, wieder andere versuchen jede einzele Funktion zu bewerten, nach nötigen Programmzeilen (COCOMO Verfahren), wieder andere verwenden die Delhi Methode, wieder andere schätzen auf der Basis des Gefühls, etc. pp.

Allgemein gilt, dass ein Festpreis für den Lieferanten (in einem Fall, dich), das grösste Risiko liegt. Bei einem Cost+Materials Project sind die Seiten gedreht. Dazwischen gibt es tausende verschiedene Varianten, wie Cost-Plus, Kostendach, etc.

Bei einem Projekt, wo die Anforderungen komplett schwammig sind, wie in deinem oben skizzierten Fall, grenzt es schlicht und einfach an Selbstmord einen Festpreis abzugeben, ausser man kaluliert dermassen Grosszügig, dass der Kunde mit Sicherheit ablehnt :wink:

Im Übrigen, ist es vollkommen Jacke wie Hose, wer das Pflichtenheft ausarbeitet. Wichtig ist einzig, dass es den Leistungsumfang genau genug spezifiziert. Alles was nicht definiert ist, gibt Change-Requests mit neuen Einnahmequellen (sofern das Lastenheft nicht zu grosszügig definiert ist :pale:).

So, denn mal viel Spass.

[haentschman]

Zitat:

ausser man kaluliert dermassen Grosszügig, dass der Kunde mit Sicherheit ablehnt

... das das auch unter Umständen in die Hose geht hab ich selbst erfahren. Auch wenn es nicht damals nicht die Softwarebranche betraf, ich wollte den Auftrag nicht... Pech gehabt. Wenigstens konnte ich mich dann über einen Stundenlohn von ca. 1500 DM freuen bei einem Tag Arbeit. 8-)

... aber die Zeiten sind lange vorbei :?

[RWarnecke]

Hallo zusammen,

danke für eure Antworten. Da ich nur eine grobe Umschreibung der Funktionen und Masken erhalten habe, werde ich das ganze Projekt nach Aufwand kalkulieren. Ich werde eine ungefähre Hausnummer an Stunden abgeben zu einem bestimmten Stundenpreis. Damit bin ich sehr flexibel, was eventuelle Änderungen und Erweiterungen angeht. Ich bin mir auch im Klaren darüber, dass wenn der Kunde zusagt, dass das Programm zu einer Lebensaufgabe werden kann. Das wäre mir allerdings egal. 8-)

Die andere Variante wäre noch, dass meine Kunde es ablehnt nach Aufwand zu bezahlen. Dann müsste ich mir doch noch überlegen, wie ich den Festpreis ermittel.

[blackfin]

Zitat:

Die andere Variante wäre noch, dass meine Kunde es ablehnt nach Aufwand zu bezahlen. Dann müsste ich mir doch noch überlegen, wie ich den Festpreis ermittel.

Als "Zwischenlösung", um den Auftraggeber nicht gleich beim Preis vom Stuhl zu hauen, bietet sich auch oft folgende, zusätzliche Vorgehensweise an:

Du schliesst im Pflichtenheft beim Grundangebot erstmal alle Dinge aus, bei denen du etwas Bauchweh hast, die relativ schwammig beschrieben sind oder bei denen du denkst, das könnte ein Faß ohne Boden sein. Heisst, du bietest erstmal nur Dinge zum Festpreis an, die die Grundfunktionalität beinhalten und bei denen du sicher bist, dass du dich nicht völlig verkalkulierst.
Aber! Du schliesst die "Bauchweh- und Risiko-Features" nicht direkt aus, sondern schreibst, mit einer doch etwas grösser definierten Hausnummer dazu, was es ungefähr kosten würde, dieses Feature doch zu implementieren, oder, dass für dieses Feature nicht auf Festpreis-Basis programmiert werden kann, da es im Vorfeld nicht ganz abschätzbar ist, wieviel Aufwand es im Endeffekt bedeutet (evtl. mit einfacher, technischer Begründung).

Das resultiert dann am Ende des Pflichtenhefts in einer Hausnummer für das "minimale Gesamt-Angebot", die den Auftraggeber erstmal lächeln lässt, ohne dass er einen Schock bekommt, aber meistens will er viele der Bauchweh-Dinge, die den Preis im Endeffekt hochtreiben, dann doch.
Und so trifft man sich am Ende irgendwo in der Mitte und du hast nicht das extreme Risiko, das komplette Projekt zum Festpreis anzubieten.

[Hansa]

Zitat:

Zitat von RWarnecke (Beitrag 1112940)

Da ich nur eine grobe Umschreibung der Funktionen und Masken erhalten habe, werde ich das ganze Projekt nach Aufwand kalkulieren.

...womit wir wieder am Anfang wären...

Die verlinkten Sachen geben auch nicht viel her. Teils ist das zwar richtig und teils verkehrt, passen tuts aber jedenfalls nie richtig.

Also gilt klassisches Prinzip : 1/3 bei Auftragserteilung, 1/3 bei Auslieferung und der Rest eben irgendwann. Dabei kommt man um die Hausnr. nicht rum, also gilt es zu schätzen. Bsp.: Rechnungsprogramm. Eine Rechnung kann man kaum schreiben ohne Artikel oder Kunden. Dazu braucht man dann eben entsprechende Stammdaten-Verwaltung und der Aufwand lässt sich sicher ziemlich genau ermitteln.

Aber da lauern noch mehr potentielle Fallen. Es sieht hier so aus, als gingen die Bedenken in Richtung "Vorsicht ! das wird mehr Arbeit als gedacht, also besser direkt mehr verlangen".

Jo, ist schon halbrichtig. Aber sagen wir mal Indy-Komponenten werden gebraucht und man kennt die nicht richtig, dann kann man dem potentiellen Kunden jedenfalls nicht den Aufwand aufs Auge drücken. Ausnahme : man braucht die nie wieder, weil das eine einmalige Sache ist.