In der Praxis ergeben sich oft
Probleme:

• Die Anforderungen des Kunden ändern sich während der Projektlaufzeit (dieses Problem wächst dramatisch mit steigender Laufdauer des Projektes)
• Die Spezifikationen sind nicht ausreichend vollständig und konsistent und bedürfen der Nachbesserung (Zusätze)
• Die Qualität ist nicht hinreichend spezifiziert. Die Software funktioniert zwar, der Kunde ist trotzdem nicht glücklich.

Was ist hier genau mit Qualität gemeint ?

• Termine oder Preise können nicht gehalten werden und unterliegen der Neuverhandlung (Ärger, Budgetüberschreitungen, WerIstSchuld?)
• ...

Vorteile FestpreisVertrag für den Lieferanten:

• Normalerweise war es bisher leichter, ein Projekt auf diese Art zu verkaufen.
• Wenn ein Projekt überteuert verkauft wird, kann dies der Kunde nicht erkennen.
• Ein FestpreisVertrag ist oft eine unumstössliche Forderung des Kunden.
• ...

• Der Großteil des Risikos liegt beim Lieferanten (Nachteil vor allem für kleine Lieferanten)
• Hoher Aufwand in der guten Vorbereitung eines Projektes (wenn hier der Kunde oder der Lieferant spart, erzeugt das automatisch Probleme)
• ...

ExtremeProgramming verspricht diese Probleme unter Verzicht auf einen FestpreisVertrag in einem Entwicklungsteam "normaler" Qualität durch eine Methodologie zu lösen.

Gedanken dazu:

• Ein FestpreisVertrag versucht dem Kunden Sicherheit zugeben, indem er zusichert ein Produkt zu einem bestimmten Preis zu einem bestimmten Termin abzuliefern. Das Risiko wird offenbar vom Kunden zum EntwicklungsTeam? verschoben.

Falsch: Der Lieferant versucht dem Kunden zu vermittelt, dass es bei Abschluss eines Vertrages kein Risiko gibt. Erfahrene Entwickler liefern bewährte Qualität. Es gibt keine Probleme.

Weshalb so kategorisch "Falsch" ? Ich kann mir auch Kunden vorstellen, die mit ihrer zusätzlichen Gestaltungsfreiheit nicht umgehen können, bzw. die von Ihnen geforderten Entscheidungen (Feature A oder B) ohne Blick auf evtl. weitreichenden Konsequenzen fällen.

Da hast du völlig recht, vielleicht habe ich die obige Formulierung - aus Sicht der Projektaquisition und Verkaufspsychologie - überinterpretiert. Was ich meinte ist, dass es für den Kunden im FestpreisVertrag kein wichtiges Motiv sein kann, das Risiko zu verlagern. Wenn er ein Risiko sieht, wird er mit dem Abschluss zögern oder einen anderen Lieferanten wählen. Deshalb wird der Lieferant auch vermeiden, von Risiken zu sprechen. Das gilt für den Entwicklungsbereich ebenso wie für den Kundenbereich (weil er damit die Kompetenz des Kunden anzweifeln würde). Vermutlich muss jemand, der erfolgreich Projekte verkaufen will, Worte wie "Risiko" oder "Problem" aus seinem Wortschatz streichen.

Ich hoffe nicht ! Ich denke es ist die Kunst, trotz "Risiko" und "Problem" genügend Vertrauen zu erzeugen. Ich hoffe weiterhin, dass zufriedene, ehemalige Kunden diesem Vertrauensvorschuss dienlich sind :-). Ist dieses Vertrauen vorhanden, ist ein Festpreis eine Richtgrösse, für die der Kunde ein lauffähiges & zufriedenstellendes Produkt bekommt. Die Detailfunktionalität kann dabei genauso im Fluss bleiben, wie das in XP vorgeschlagen wird.

• Ich denke nicht, dass ein Projekt an einem Festpreis Vertrag zugrundegeht, sondern an den grundsätzlichen und unausgeräumten Konflikten. Die erfolgreichen und befriedigenden Projekte, die ich erlebt habe, hatten immer ein beiderseitegen Willen zum Erfolg zur Vorraussetzung. Stellt sich also die Frage, ob eine konstruktive Zusammenarbeit eher durch die eine oder die andere Vertragsform erreicht werden kann ... imho gibt es da keine wesentlichen Unterscheide.

Von den VierVariablen lassen sich Umfang und Qualität des Produktes schwer eindeutig festhalten und somit Raum für Interpretation. Insbesondere wenn sich die Realisierung als schwerer als erwartet herausstellt, ist das Entwicklungsteam praktisch gezwungen, die Anforderungen zu Ungunsten des Kunden auszulegen. Anstatt des innerhalb der zur Verfügung stehenden Resourcen bestmöglichen Produktes, bekommt der Kunde ein minderwertiges, bei dem an allen möglichen, vom Kunden nicht mehr beeinflussbaren Ecken gespart wurde. Die Verlagerung des Risikos ist so im Großen und Ganzen eine Illusion.

Würde ich so nicht unbedingt sagen. Solche Projektverläufe kommen zwar vor, die oben beschriebenen Probleme können aber anders gelöst werden. Das Versagen eines Festpreis Projekts hat die gleichen Gründe, die auch zum Versagen eines Dienstleistungs Projekts führen. Für mich hat ein FestpreisVertrag folgende Daseinsberechtigung:

• Kunde benötigt eine Rechengrösse, die für Ihn verständlich ist. Das ist eine zusätzliche Dienstleistung am Kunden.

Das PlanungsSpiel gibt dem Kunden neben dieser Rechengröße zusätzlich Einblicke in die Zusammensetzung und Dynamik dieser Größe - und Mittel, auf die Dynamik aktiv und zeitnah zu reagieren. Ein FestpreisVertrag ist dafür nicht notwendig.

Ich denke das ist eine Wunschvorstellung. Meist möchte der Kunde (wie ich ihn bis jetzt kennengelernt habe) sich nicht derart tief in sein eigenes Projekt einarbeiten...

Aber ist nicht genau das ein Problem des FestpreisVertrages - dass dem Kunden suggeriert wird, es wäre auch gar nicht notwendig, sich um das Projekt zu kümmern? Oder ist es gar tatsächlich Deine Erfahrug, dass es nicht notwendig ist?

Klar, ein Projekt ohne Kundenbeteiligung kann nicht erfolgreich sein. Allerdings sind es nicht immer die Entscheidungsträger, die zum einen den nötigen Input liefern könne und zum andern haben die Entscheidungsträger noch viele "wichtige" andere Aufgaben zu bewältigen, stehen also gar nicht für den XP Ansatz zur Verfügung. In diesem Umfeld habe ich schon Projekte erfolgreich (beiderseits ... denke ich) zum Abschluss gebracht.

• Ein IT Projektteam hat i. R. mehr Erfahrung mit der Abwicklung von IT Projekten, kann also auch eine bessere Projekt-Einschätzung vornehmen.

Deswegen sind im PlanungsSpiel die Entwickler für die AufwandsAbschätzung? zuständig.

Ja, aber der Kunde trifft letztendlich die Entscheidungen (strategische). Wenn sich der Kunde nun nicht wirklich die Mühe macht, sich einzuarbeiten / -denken, sind das nicht immer gute Entscheidungen.

Heißt dass, das EntwicklungsTeam? ist in diesem Fall besser beraten, selber die GeschäftsEntscheidung?en für den Kunden zu treffen?

Nein das Entwicklungsteam kann aber die Zahl der nötigen Entscheidungen reduzieren und die Entscheidungskriterien dann kundenverständlich aufarbeiten. Kleine Entscheidungen können dann mit dem Vertreter vor Ort ausgearbeitet werden, die grossen Tiere muessen dann nur noch für wenige weitreichende Entscheidungen hinzugezogen werden.

• Durch die fehlende zeitlichen und/oder finanzielle Terminierung des Projekts kommen ohne extreme Selbsdiziplin letztendlich längere Projektlaufzeiten zustande.

Es gibt andererseits Untersuchungen [PeopleWare] die zeigen, dass eine zu enge Zeitplanung die Produktivität des Teams verringert. Das PlanungsSpiel ist bemüht, einen (nach aktuellem Wissensstand) möglichst realistischen Zeitplan aufzustellen, trägt aber auch dem Umstand Rechnung, dass es sich eben "nur" um Schätzungen handeln kann.

Unwiedersprochen. Man kann in jedem Vorgehensmodel unzählbar viele Fehler einbauen :-)

• Auch ein XP-Projekt ist nicht vor Konflikten sicher. Stichwort "diese Abschätzung kann ich dem Kunden nicht zumuten...".

Solche Probleme sollten durch die kurzen Iterationen recht schnell offensichtlich werden. Ist das ein generelles Problem, so schlägt sich das implizit im WetterVonGestern nieder. (Handelt es sich nur im eine einzelne AnforderungsGeschichte, so sollte man sie vielleicht nochmal aufteilen?)

Das Problem ist eher, dass man schon viele ähnliche AnforderungsGeschichten in der Zeit x bewältigt hat und nun (vielleicht wg. einem Redesign o. ä.) für eine neue, ähnliche AnforderungsGeschichte die Zeit x * 5 benötigt. Da wird der Kunde misstrauisch - auch hier läuft das ganze wieder auf gegenseitiges vertrauen-können und den Willen, gemeinschaftlich etwas zu erreichen, hinaus.

Und auf ehrliche und umfassende Kommunikation. Ich könnte mir auch vorstellen, dass der KundeVorOrt hier hilft, das Vertrauen zu stärken.

Ja das ist richtig, das Problem ist dann aber natürlich, den richtigen Kundenvertreter vor Ort zu haben ... Den Kunden gibt's nämlich nicht, da sind immer viele Parteien beteiligt !

• Z. B. der XP Ansatz KundeVorOrt wirkt dem Scheitern von XP-Projekten entgegen. Ein Kunde vor Ort ist aber auch bei einem FestpreisVertrag eine ausgesprochene Hilfe.

Ohne Zweifel.

Ich will nicht sagen Festpreis ist um jeden Preis zu bevorzugen, aber ich will nicht aus Glaubensgründen darauf verzichten muessen.

Selbstverständlich geht es nicht um Glaubensgründe oder darum, den FestpreisVertrag zu verteufeln. (Habe ich den Eindruck erweckt?) Es geht lediglich darum, einige potentielle Probleme aufzuzeigen und Alternativen anzubieten.

:-) Ack. Weisst du, ich glaube, ich meckere nur, weil ich hier die Alternativen noch nicht entdeckt / gelesen habe. Gibt's irgendwo schon eine Zusammenfassung mit Vor- und Nachteilen der jeweiligen Prozessspezifischen Methoden ?

Die einzige mir bewusste Abhandlung über eine Alternative ist WardsWiki:OptionalScopeContracts.

• für jede Iteration gibt es einen festen, eher niedrig angesetzten Betrag nach Aufwand
• für festgelegte funktionale Meilensteine gibt es deftige Prämien

news:comp.software.extreme-programming

Contracts aren't about agreeing to everything up front, because agreeing to everything up front is simply impossible. Contracts are about establishing a framework within which the parties can trust each other. There will always be exceptions and oversights. If the relationship is built on trust, then these situations are dealt with accordingly. If the relationship is not built on trust, then the contract should not be signed.

• WardsWiki:FixedPriceContract
• WardsWiki:FixedPriceContractsWithChangeControl
• WardsWiki:OptionalScopeContracts
• http://www.poppendieck.com/agilecontractsworkshop1.htm