Maximaler Nutzen in vorgegebener Zeit und vorgegebenem Budget Agile Festpreisprojekte in der Praxis

Teil 1:
Das Vorgehen im Überblick
Agile Festpreisprojekte in der Praxis

Ihr Produkt muss zu einem fixen Zeitpunkt und gegebenen Budget fertig werden? Dennoch braucht der Auftraggeber Flexibilität? Autor Tassilo Kubitz erklärt anhand eines Praxisbeispiels, wie Sie die konträren Interessen mit einem agilen Festpreisprojekt vereinen.

Management Summary

Download PDFDownload PDF

Maximaler Nutzen in vorgegebener Zeit und vorgegebenem Budget Agile Festpreisprojekte in der Praxis

Teil 1:
Das Vorgehen im Überblick
Agile Festpreisprojekte in der Praxis

Ihr Produkt muss zu einem fixen Zeitpunkt und gegebenen Budget fertig werden? Dennoch braucht der Auftraggeber Flexibilität? Autor Tassilo Kubitz erklärt anhand eines Praxisbeispiels, wie Sie die konträren Interessen mit einem agilen Festpreisprojekt vereinen.

Management Summary

Wir empfehlen zum Thema Vorgehensmodell
12.09.2024
1.395,00,-
Hybrides Projektmanagement - das Beste aus 2 Welten vereinen

Lernen Sie das Wichtigste beim Einsatz von hybridem Projektmanagement, damit auch Sie in Ihrem Unternehmen das Beste aus zwei Welten kombinieren. Mehr Infos

Dass Ihr Projekt zu einem bestimmten Zeitpunkt und in einem bestimmten Kostenrahmen fertig wird, ist Ihnen wichtiger als der Umfang? Der Festpreis will aber nicht passen, weil laufend neue Anforderungen dazu kommen oder bestehende Anforderungen geändert werden? Dann braucht es etwas anderes als einen Festpreis oder den Einsatz von Agilität. Aber was?

In meinem zweiteiligen Beitrag stelle ich Ihnen den agilen Festpreis vor, der einen Mittelweg aus Festpreis und agilem Vorgehen darstellt. Die Empfehlungen resultieren aus mehreren agilen Festpreisprojekten sowie einem konkreten Software-Projekt. Wie Sie mit einem Teilprojekt von Anfang an partnerschaftlich zusammenarbeiten, eine Roadmap und den Vertrag erstellen sowie laufend den größten Kundennutzen im Blick haben, erfahren Sie im ersten Teil. Im zweiten Teil finden Sie die notwendigen Instrumente und Methoden für das beschriebene Vorgehen.

Ein agiler Festpreis passt für Ihr Projekt, wenn

  • Sie einen festen Budgetrahmen haben und die Anforderungen noch sehr vage sind.
  • Sie keine Zeit haben, den Scope exakt zu definieren, also der Scope größtenteils unklar ist, aber dennoch variabel sein kann.
  • Sie partnerschaftlich zusammenarbeiten und Vertrauen vorhanden ist.
  • Sie flexibel agieren müssen und am Ende des Budgets der maximale Nutzen stehen soll.
  • Sie einen Projektstau abarbeiten müssen, indem Sie sich auf den Mehrwert fokussieren und eine optimale Auslastung Ihres Teams von Research, Development und Testern erzielen wollen.

Software-Projekte (z.B. Weiterentwicklung von internen oder externen Produkten / Projekten) eignen sich besonders für einen agilen Festpreis, da eine Releaseplanung möglich und damit das passende Schneiden des maximalen Mehrwerts bei fester Budgetgrenze leichter ist. Aber auch bei Organisationsentwicklungsprojekten, wie der Einführung eines neuen Geschäftsprozesses, kann ein agiler Festpreis sinnvoll sein.

Projektbeispiel: Software-Entwicklungsprojekt für ein Maschinenbauunternehmen

Ein Software-Entwicklungsprojekt für ein Maschinenbauunternehmen hatte Anfang 2016 geendet. Es war mit klassischem Festpreis und vollem Risiko beim Auftragnehmer geplant und umgesetzt worden. Die Laufzeit hatte sich um mehr als 12 Monate verlängert und die Kosten waren durch Gewährleistungsansprüche und Nachforderungen auf etwa das Doppelte gestiegen. Das beiderseitige Vertrauen hatte gelitten. Es konnten nicht alle Anforderungen umgesetzt werden. Dem Projektergebnis, der Software, fehlte es noch an weiteren Funktionalitäten, um sie in der Breite im Markt zu positionieren. Ein weiteres Projekt sollte die vorhandenen Lücken schließen.

Zu diesem Zeitpunkt wurde mir das Projekt übertragen. Beide Seiten waren sich einig: Das gemeinsame Vorgehen muss anders gestaltet werden. Der Auftragnehmer wollte nicht alleine auf dem Risiko von Kostensteigerungen sitzenbleiben. Der Auftraggeber mahnte Termin- und Budgettreue an. Wir entschlossen, ein agiles Festpreisprojekt zu vereinbaren.

Das bedeutete konkret:

  • Die Einhaltung von Budget und Terminen war wichtiger als der Scope – ein Budgetrahmen und ein Projektende wurden definiert.
  • Die Features wurden nicht bis ins letzte Detail ausformuliert, sondern über den zu erreichenden Kundennutzen beschrieben und mit einem Anteil des Gesamt-Budgets versehen.
  • Die Planung der Umsetzung erfolgte als Roadmap von Features.
  • Gemäß der Reihenfolge in der Roadmap wurden die Features während des Projekts konkretisiert.
  • Die Umsetzung der Anforderungen erfolgte in vielen Teilprojekten als Feature-Releases, um jedes Mal einen Mehrwert im Markt zu erzeugen. Es gibt die Möglichkeit, auch zwei Features gleichzeitig zu planen und auszuarbeiten.
  • Die Projektsteuerung erfolgte partnerschaftlich und gemeinsam.

Der Entschluss für das agile Festpreisprojekt war gefasst, die übergeordneten Ziele hinsichtlich Budget, Termineinhaltung und Scope geklärt. Doch wie setzt man nun im Detail so ein agiles Festpreisprojekt auf?

Partnerschaftliches Zusammenarbeiten von Anfang an

Operativer und strategischer Lenkungsausschuss

Im agilen Festpreisprojekt gibt es einen operativen Lenkungsausschuss, im Folgenden das "Gremium" genannt, und einen strategischen Lenkungsausschuss, wie man ihn aus klassisch durchgeführten Projekten kennt.

Das Gremium besteht aus je einem Ansprechpartner von Auftragnehmer und Auftraggeber. Der Ansprechpartner auf Auftragnehmer-Seite sollte ein gutes Verständnis für Architekturen mitbringen. Das Gremium hat die Befugnis, innerhalb eines festgesteckten Rahmens von Budget und Funktion selbstständig Entscheidungen zu treffen, ohne den strategischen Lenkungsausschuss zu fragen, z.B. wenn es Änderungen bei einem Feature gibt. Wenn ein Feature ganz entfällt oder ein Feature ganz neu dazukommt, dann muss das Gremium den strategischen Lenkungsausschuss miteinbeziehen. Das Gremium berichtet an den strategischen Lenkungsausschuss.

Beispiel

In meinem Projekt setzte sich das Gremium aus dem Projektleiter des Auftragnehmers und mir zusammen.

Entscheidungen gemeinsam treffen

Fortsetzungen des Fachartikels

Teil 2:
Methoden im agilen Festpreisprojekt

Wie wird aus einer groben Anforderung ein konkretes Bündel an Arbeitspaketen? Wie berücksichtigt man Kosten, Nutzen, Komplexität und Mehrwert beim Endkunden in diesem Prozess? Tassilo Kubitz setzt für genau diese Fragestellungen auf Impact …

Alle Kommentare (3)

Rüdiger
Geist

In diesem Beitrag bleibt m.E. einiges unklar, was den Begriff "Festpreis" betrifft. Festpreis heisst zunächst einmal nichts anderes, als dass ein festgelegter Preis zu bezahlen ist. Wofür, ist über den Begriff nicht definiert. Der Inhalt des Artikels legt die Vermutung nahe, dass der Autor, wenn er von "klassischem Festpreis" spricht, einen "Werkvertrag zum Festpreis" meint, was ich aus den Textteilen zum Thema "Risiko" und "design2cost" ableite. Warum ist das wichtig? Weil der Artikel fast völlig ausblendet welche rechtlichen Konsequenzen sich aus einem Werkvertrag während und auch nach Abschluss des Projektes ergeben. An zwei Stellen im Artikel wird ein wenig darauf eingegangen: "partnerschaftliches Zusammenarbeiten" und "geteiltes Risiko" anhand der kundenseitigen Priorisierungen. Partnerschaftlichkeit ist bei allen Verträgen von Bedeutung und ganz bestimmt bei Werkverträgen zum Festpreis, aber das war schon immer so. Was de Autor als "geteiltes Risiko" bezeichnet, ist aber tatsächlich kein geteiltes Risiko. Das gesamte Risiko bleibt rechtlich beim Auftragnehmer, denn die Priorisierung durch den Auftraggeber regelt ausschliesslich wie der Scope bestimmt wird, hat aber Null Konsequenz auf das was einen Werkvertrag ausmacht, nämlich dass ein Werk (Erfolg) geschuldet ist. Wie der Prozess der Definition des Werkes zustande kam, spielt dabei keine Rolle. So kann sich z.B. ein Dachdecker bei später festgestellten Mängeln nicht darauf berufen, dass der Bauherr sich im Verlauf doch für die günstigeren Dachziegel entschieden hat. Auch die Frage, wie denn das Werk beschrieben sein muss, damit überhaupt die Erfüllung nachweisbar ist, bleibt einigermassen vage. "Epics und Feature, formuliert als Sales Stories", also die Beschreibung einer Anforderung auf einer hohen Abstraktionsebene und die Beschreibung von Produkteigenschaften, formuliert als eine Art Nutzen aufzeigendes Verkaufsgespräch? Ich bin ein grosser Verfechter der Idee, partnerschaftliche Zusammenarbeit vor wasserdichte Verträge zu setzen, da diese eh nie 100%-ig sein können. Aber mit Risikoverteilung hat dies nichts zu tun. Und der Nutzen ist auch nicht das was abgenommen wird. Und wirklich problematisch wird es, wenn "die Definition of done für die Abnahme der Features" (also das Abnahmekriterium für die Produkteigenschaften) "durch den Auftraggeber" festgelegt werden sollen. Und die Überprüfung erfolgt anhand "(Testprotokolle und Benutzerdokumentation)". Was wenn nach Projektabschluss Mängel auftreten? Eine Abnahme durch den Auftraggeber beeinflusst nicht die Gewährleistungspflichten. Was wenn sich im Laufe des Projektes das Verhältnis zwischen AG und AN von "partnerschaftlich" zu "weniger partnerschaftlich" verändert? Vielleicht wird ja im zweiten Teil dazu Stellung bezogen. Bin gespannt.

 

Sehr geehrter Herr Geist, vielen Dank für Ihren Kommentar. Ich möchte auf die wesentlichen Punkt von Ihnen eingehen: - Die üblichen Gewährleistungspflichten bleiben natürlich unberührt und sind ebenfalls Basis der Zusammenarbeit. Der AN sollte als Technologie-Experte wissen, welche Materialien einsetzt. Darauf muss sich der AG verlassen können. - Die Definition of Done bestehen aus der Liste der allgemeinen Artefakte. Die Akzeptanzkriterien gehören zu den gemeinsame definierten Eigenschaften der Features im Backlog. Diese bestimmt der AN natürlich mit. - Die partnerschaftliche Zusammenarbeit setzt voraus, dass man gemeinsam den Scope innerhalb der Vision/Sales Stories definiert. Das erfolgt nicht einzig durch den AG. Die gemeinsame Priorisierung des "Backlogs" und das Schneiden des Umfangs mit dem Fokus den Nutzen innerhalb eines festen Budgetrahmens zu maximieren ist das Fundament. Die dafür passenden Methoden werde ich in der Tat erst im zweiten Teil ausführlicher Beschreiben. Viele Grüße Tassilo Kubitz

 

Matthias
Eberspächer
Dr.

Hallo Herr Kubitz,

schöner Artikel, die Idee mit der "Zusammenarbeits-Simulation" gefällt mir sehr gut - das werde ich klauen! ;o)

Das Modell mit den Bauklötzen erinnert mich an folgendes Vorgehen, dass ich so auch schon verwendet habe. Zu jedem Feature schätzt der AG den Nutzen, z.B. auf einer Skala von 1 - 10 (1= höchster Nutzen, 10 = niedrigster Nutzen). Parallel dazu schätzt der AN die Kosten, der Einfachheit halber ebenfalls auf einer Skala von 1 - 10 (1 = niedrigste Koste, 10 = höchste Kosten). Beide Schätzungen erfolgen jeweils ohne die Kenntnis der anderen Schätzung. Danach werden die Features nach dem Produkt beider Schätzungen aufsteigend sortiert: Ganz oben stehen dann die Features mit den geringsten Kosten und dem höchsten Nutzen. Dieses Verfahren eignet sich besonders bei einer unübersichtlichen Vielfalt von Features, die man nicht leicht überblicken kann.

Herzliche Grüße,

Matthias Eberspächer