Festpreisprojekte

“Festpreisprojekte – ein vorausschaubares Vertragsmodell mit einem festen Budget”

Bei Festpreisprojekten sollte alles möglichst fest sein – Kosten, Aufwand und Projektumfang. Sind feste Zeit- und Kostenvorgaben ein Ausscheidungskriterium für Teams, die es gewohnt sind, agil zu arbeiten?

Festpreisprojekte dienen in der Regel dazu, entweder eine mögliche Zusammenarbeit mit einem neuen Dienstleister auszuprobieren, oder die Durchführung eines abgrenzbaren Projekts ohne jegliche Teilnahme am Prozess auszulagern. Oft geht es Kunden darum, nicht nur die Projektausgaben abzugrenzen, sondern auch den genauen Umfang der Funktionalitäten festzusetzen. Eine häufige Falle dabei ist die Annahme, dass man durch eine detaillierte Beschreibung des Projektumfangs, das Projekt eigentlich auch ohne einen externen Partner durchführen könnte.

Softwareentwicklung und Softwaretesting können auf unterschiedliche Weise durchgeführt werden. Bei der Auswahl des Festpreisprojektmodells gilt die goldene Regel - den anderen arbeiten lassen. Aus diesem Grund sollte man für eine erfolgreiche Durchführung des Projekts auf die gemeinsame Erfassung der 3 wichtigsten Bestandteile im Prozess mit dem Entwicklungspartner hinweisen:

  • Erfassung der User Stories
  • Einschätzung der Story Points
  • Vereinbarung der Definition of Done

Man sollte sich darüber im Klaren sein, dass ein höheres Maß an Details in der Spezifikation von Softwareanforderungen für beide Parteien zwei völlig unterschiedliche Dinge bedeutet. Softwareunternehmen konzentrieren sich in der Regel auf technische Details, während der Kunde eher geschäftsorientiert ist. Spezifikationen werden grundsätzlich vom Softwareentwicklungsunternehmen erstellt und festgeankert.

Auf der Basis einer gründlichen Voruntersuchung kann dann eine realitätsnahe Einschätzung für Festpreisprojekte abgegeben werden. Wenn diese nicht Ihren Erwartungen entspricht, dann müssen die Anforderungen noch weiter ausgearbeitet werden.

Technosoft - fixed priceVoruntersuchung

Der schwierigste Teil bei der Vorbereitung eines Festpreisprojekts ist die Festlegung des Preises und des Zeitplans, beide können nur auf Grund eines klar definierten Umfangs festgelegt werden. Die Erfassung der User Stories kann in mehreren Sessions stattfinden, die insgesamt nicht mehr als 1 oder 2 Tage in Anspruch nehmen sollten. An dieser Stelle ist es wichtig, die Definition of Done für User Stories, Iterationen und Releases mit dem Kunden zu vereinbaren.

Um die User Stories optimal zu strukturieren, sind u.a. folgende Fragen zu beantworten:

  • Wie werden User Stories abgenommen? (Umgebung und Verantwortliche)
  • Welche Projektdokumentation wird erwartet?
  • Welche Beileistungen seitens des Kunden werden benötigt?
  • Deployment-Umgebung und Infrastruktur
  • Zeitplan regelmäßiger Meetings

Wichtig dabei ist es, möglichst viele zukünftige Projektteilnehmer im Prozess zu engagieren, damit die Einschätzung gemeinsam erfolgt. Unsere Business-Analysten, Lead-Entwickler und QA-Manager stehen Ihnen zu diesem Zweck mit ihrem gesamten Wissen und Branchen-Know-how zur Verfügung.

Im Rahmen der Voruntersuchung geht es u.a. um die Ermittlung der Geschwindigkeit des geplanten Teams. Um Zeit- und Kosteneinschätzungen für Festpreisprojekte abgeben zu können, müssen wir die Geschwindigkeit (team velocity) anhand folgender Ausgangskriterien bestimmen:

  • Geschwindigkeit des Teams bei früheren Projekten
  • Anzahl der Aufgaben, die in jeder Iteration zu erledigen sind (ausgehend von der Definition of Done)
  • Kommunikationsbereitschaft der Stakeholder des Kunden – je weniger Zeit für spontane Anfragen zur Verfügung steht, desto geringer fällt die Geschwindigkeit aus

Angenommen wir verfügen über ein Team von 5 Projektteilnehmern - 3 Programmierern, 1 Tester und 1 Teamleiter, die mit Kunden und Stakeholdern sowie mit anderen Personen außerhalb des Teams kommunizieren werden (wie z.B. mit dem Scrum Master).  Wenn wir jetzt davon ausgehen, dass unser Team eine Geschwindigkeit von 20 Story-Punkten für jede Iteration (2 Wochen) anstreben wird, dann können wir diese Team velocity als Grundlage für die weitere Berechnung der bevorstehenden Aufwände verwenden.

Zwar können viele externe Faktoren die Geschwindigkeit beeinflussen, aber wenn das Team bereits eingearbeitet ist und vergleichbare Festpreisprojekte bereits abgeschlossen hat, trennt uns von der eigentlichen Auftragsvergabe nur noch die Übernahme der Risiken und die Abgabe der Einschätzung dem Kunden gegenüber.

QA Tester, qa testers, QA Testing, Software Testing, Testing Software, Smoke Test, STLC, IT Nearshoring, Nearshoring, Nearshore-Softwareentwicklung, nearshoring software, it testsit nearshoring, software-refactoring, Software-Lebenszyklus, testmanagement, Testautomatisierung, software testen, QA Testing Software, DevOps Service, DevOps Beratung

  • Ausgearbeitete User Stories
  • Eingeschätzte Story Points
  • Festgelegte Definition of Done
  • Voruntersuchung der Zeit- und Kostenaufwände

Egor Gucinski - Certified Scrum Master

Warum sind einige Kunden von Festpreisprojekten besessen?

Festpreisprojekte werden oft als sehr schädlich für die Partnerschaft zwischen zwei Unternehmen angesehen, und viele agile Spezialisten meinen, dass wir sie einfach vermeiden sollten. Manchmal können sie nicht vermieden werden, also müssen wir Wege finden, gemeinsam mit unserem Kunden das gesetzte Ziel zu erreichen - nämlich gute Software zu entwickeln.

Aus meiner Praxis heraus habe ich festgestellt, dass einige Aspekte von Festpreisprojekten eigentlich besser für agile Teams sind, da wir es uns gewohnt sind, innerhalb von fest definierten Zeitrahmen zu arbeiten. Und das ist genau, was ein fester Liefertermin in einem Festpreisvertrag eigentlich bedeutet: ein klar vorgegebener Zeit- und Funktionalitätsrahmen. Das Einzige was uns wirklich bei Festpreisprojekten stört, ist der Versuch des Kunden, sich über ein Festpreisprojekt mehr Sicherheit seinem Partner gegenüber reinzuholen. Und genau darum geht es - Vertrauen.

Wir wissen, dass man allein von der Aussage, was für eine großartige Arbeit unser Team für unsere Kunden leisten kann, nicht ausreichend Vertrauen von neuen Kunden erweckt. Hier kommen die Agile Prinzipien  ins Spiel, um dieses Problem zu lösen. Denn mit jeder Iteration sind wir in der Lage, einen gehobenen Mehrwert für unseren Kunden zu schaffen. Aber was noch wichtiger ist, wir konzentrieren uns darauf, zuerst die wichtigsten Features anzuliefern. Die gelieferte Software muss beim Kunden Vertrauen wecken. Es soll bereits einige Arbeitsteile der wichtigsten Funktionalitäten enthalten. Funktionierende Software ist der beste Beweis dafür, dass man den Rest ebenfalls bauen kann. Außerdem hat der Kunde auch die Möglichkeit, über die Geschwindigkeit (velocity) des Teams zu entscheiden und schließlich den nächsten Schritt zu machen.

Haben Sie ein Fespreisprojekt zu vergeben?

Gern schauen wir uns Ihre Anforderungen in Rahmen eines Online-Meetings an, um eine unverbindliche Zeit- und Kostenaufwandseinschätzung abzugeben.

Siehe die Entwicklung von Technosoft

1977 Heute
1998
Projektmanagementsoftware
1983
Markenregistrierung Technosoft
1984
Start der Entwicklung CAD Software
2000
Übernahme der Tätigkeiten von Brunel und Niederlassung in Deventer
2007
Technosoft Deutschland
2009
Technosoft Moldawien
2015
Technosoft Rumänien
1993
Von DOS zur Windows-Plattform
2001
Start Verkauf AxisVM Software
2014
Einführung 3Muri Erdbebensoftware + erste KOMO Zertifizierung
2013
Start Business Unit Qualitätssicherung & Testing
2011
Übergang zu Eurocodes
2012
Start von Nearshoring unter dem Markennamen In-shore
2006
Technosoft von Brunel verkauft durch ein Management Buy Out
2016
Integration der Business Units in eine einzige Geschäftseinheit
2017
Zusammenfügung aller Aktivitäten unter dem Namen Technosoft
2018
Technosoft ist aktiv in 6 europäischen Länder