Das Festpreis-Fiasko

Einmal dem Fehlläuten der Nachtglocke gefolgt - es ist niemals gutzumachen. (Franz Kafka: Ein Landarzt)

Was im Festpreisangebot verbockt wird ist oft im gesamten Projektverlauf nicht mehr zu beheben. Entsprechend gerne sträuben sich Entwickler, eine Aufwandschätzung abzugeben ("es dauert eben so lange wie es dauert"), gerade wenn man noch gar nicht sooo genau weiß was im Projekt überhaupt gemacht werden soll. Der Kunde will es eben besonders früh wissen, und wer will es ihm auch verdenken: Er muss ein Budget organisieren bevor das Projekt begonnen hat. Würden Sie ein Haus bauen (und sich massiv verschulden) ohne zu wissen was es kostet? Eben.

1. Idealerweise macht man eine technische Kalkulation auf Basis eines Fachkonzeptes und einer technischen Analyse. Das hat man beides leider in den seltensten Fällen.

2. Wenn es für die fachlichen Anforderungen nur ein knappes Briefing gibt ("wir würden gerne unsere Website um ein Shopsystem erweitern") greift die Grundregel "Eine Anwendung kann frühestens dann kalkuliert werden wenn man sie sich als Anwender vorstellen kann". Man muss also alle Seiten und alle Prozesse aufführen und grob beschreiben können. Wenn es diese Beschreibungen nicht gibt, muss man sie eben auf Basis eines kurzen Workshops oder Telefonats mit dem Kunden oder alternativ auf Basis von Annahmen selber machen. Diese kommt dann als Leistungsbeschreibung ins Angebot.
Ob die Anforderungen später im Projekt genau so umgesetzt werden ist gar nicht so wichtig, es kommt darauf an, eine Beschreibung zu haben, gegen die man Mehraufwand abgrenzen kann, falls sich die Anforderungen ändern (und das wird in der Konzeptphase mit Sicherheit passieren). Je ungenauer die Beschreibung im Angebot ist, umso wahrscheinlicher ist es, dass der Kunde sich etwas wünscht was aufwendiger ist als ursprünglich kalkuliert.Im Bereich der fachlichen Anforderungen kann man durch etwas Detailarbeit Projektrisiken recht gut in den Griff bekommen. Das gilt für den folgenden Punkt 3. nur eingeschränkt.

3. Wenn die technische Analyse nicht vorliegt, kann man versuchen, zumindest eine knappe Recherche und ein kurzes Prototyping zu machen um einen Überblick über die unklaren Technologien oder Schnittstellen zu bekommen. Für technische Risiken gibt es aber anders als für fachliche Anforderungen keine Möglichkeit, sie durch Abgrenzungen im Angebot abzufedern. Dem Kunden ist ja letztlich egal wie seine Anforderungen durch Technik gelöst werden, es macht deshalb auch keinen Sinn, Annahmen dazu im Angebot zu formulieren, denn wenn diese nicht zutreffen ist das kein vom Kunden geforderter Change sondern ganz schlicht eine falsche Annnahme des Dienstleisters.
Ausnahme: Schnittstelle zu externen- oder Kundensystemen. Hier ist es durchaus üblich etwas zu schreiben wie "Annahme: die Produktdaten werden durch einen SOAP-Webservice vom Kunden zur Verfügung gestellt".

4. Gerne vergessen werden Qualitätssicherung, Deployment ins Livesystem, Dokumentation etc. Auch hier gilt: Abgrenzen, abgrenzen, abgrenzen. Da das etwa bei technischer Doku nicht ganz trivial ist (weil man deren Detailgrad nur schwer definieren kann) muss man sich mit Krücken behelfen, wie etwa: "Erstellung einer technischen Dokumentation, Umfang ca. 20 Seiten". Auch wenn die Seitenzahl hier völlig sinnfrei scheint, so erfüllt sie doch den Zweck zumindest eine grobe Vorstellung der Leistung zu vermitteln.