publicplan E-Government Blog

Agiles Festpreisprojekt - ein Widerspruch in sich?

Blog

Kontakt

publicplan GmbH

Kennedydamm 24
40476 Düsseldorf

 

Tel +49 (0)211 635501-80
Fax +49 (0)211 635501-89

 

Torstraße 218
10115 Berlin

 

Tel +49 (0)30 6098980-80
Fax +49 (0)30 6098980-89

infoatpublicplan.de

Agiles Festpreisprojekt - ein Widerspruch in sich?

Autor
Dr. Christian Knebel
Datum

Der vorliegende Beitrag basiert inhaltlich auf dem Beitrag Agile Festpreisprojekte – Risiko oder Chance?von Tassilo Kubitz.

Festpreisprojekte umfassen exakte Beschreibungen und feste Preise für einzelne Produkte oder Entwicklungen. Im Bereich der Softwareentwicklung sind jedoch gerade agile Projekte stark vertreten. Agil bedeutet beweglich und passt in diesem Zusammenhang nicht zu den fest strukturierten Berechnungen einzelner Projektkomponenten. Denn bei der agilen Softwareentwicklung versucht man gerade durch iterative Zyklen und möglichst wenig Bürokratie das bestmögliche Ergebnis zu erzielen.

Dieser Umstand spaltet auch die Vorlieben des Projektmanagements in zwei Lager. Während die einen auf das Wasserfallmodell schwören, bevorzugen die anderen agile Vorgehensmodelle wie bspw. Scrum. Gerade hier sollte man aber durchaus auch mal die Grautöne dazwischen betrachten. Denn ausgehend von dem Ziel, dass die Kundenzufriedenheit eines der wichtigsten Erfolgsfaktoren für Softwareentwicklungsprojekte darstellt, weiß jeder Projektmanager auch, dass sich Anforderungen oder auch Ideen des Kunden mit der Zeit ändern oder auch erst im Laufe des Projekts ergeben. Bei Festpreisprojekten werden jedoch die Ziele zu Beginn des Projekts definiert. In der Regel werden diese Ziele auch erreicht. Doch wie reagiert man, wenn sich im Laufe des Projekts die Wünsche des Kunden ändern?

Man bewegt sich gerade bei größeren Projekten in einer Art Teufelskreis. Je größer das Projekt und vor allem je starrer die Vorgehensweise, desto mehr Zeit bedarf die Planung. Dadurch starten Projekte verspätet, gar nicht oder sind nach Fertigstellung schon überholt bzw. durch andere Anbieter abgedeckt. Um sich solche Änderungen einstellen zu können, gibt es zwei Möglichkeiten:

  • "Feature-Tausch": die Möglichkeit auch im laufenden Projekt Ziele reduzieren, erweitern, streichen oder zu ergänzen
  • "Release whenever you want": kleine Iterationen von etwa einem Monat ergeben eine frühzeitige einsatzbereite (Teil-) Funktionalität

Nur wenn man vor allem bei umfangreichen Projekten auf diese Möglichkeiten rücksichtnimmt, ist es möglich, genau das Ergebnis zu erhalten, was wirklich gewünscht wird. Und nur so kann man auf aktuelle Änderungen auf dem Markt reagieren.

Es gilt also:

  • Eine Sorgfältige Anforderungsanalyse. Wichtig hierbei: Die Anwendungsszenarien definieren die Umsetzung in der Datenbank. Nicht umgekehrt.
  • Ein Iteratives Vorgehen. Jede Funktionalität hat ihr eigenes Vorgehen.
  • Pareto-Prinzip. Technische Architektur und Anwenderinteraktion stehen an erster Stelle. Alle weiteren Details können im Laufe des Projektes geklärt werden.

Agile Projekte bedürfen allerdings einer sehr guten und ständigen Kommunikation. Nur so kann gewährleistet werden, dass das gewünschte Ziel auch wirklich erreicht wird. Intensive Kommunikation und ein umfangreiches Änderungsmanagement bedeuten allerdings auch höhere Kosten.

Natürlich möchten sich in einem Projekt beide Seiten - Auftragnehmer - und geber - absichern und gießen alles in einen "perfekten" Vertrag. So nehmen sich aber auch beide Seiten die Flexibilität und die Möglichkeit, die sich während eines Projektes ändernden Anforderungen zu berücksichtigen und somit das wirklich richtige Ergebnis zu erhalten und nicht eins, von dem man zu Beginn dachte, es wäre es.  

Das Geld spielt natürlich bei jedem Projekt eine zentrale Rolle. Egal ob Top-Down oder Bottom-Up, eine Aufwandsschätzung steht am Anfang eines jeden Projektes. Allerdings muss man immer beachten, dass eine solche „Schätzung“ nicht alle, sondern nur die wesentlichen Aspekte beinhalten kann. Das ist gewollt und auch Bestandteil des iterativen Vorgehens in Projekten. Nur so lässt sich eine Kosten-Nutzen-Analyse zu Beginn durchführen.

Bei einem agilen Festpreisprojekt gibt es keine versteckten Risikoaufschläge, da ein beiderseitiges Bekenntnis zum gemeinsamen Tragen des Risikos besteht. Obwohl nicht jeder Schritt fest vordefiniert ist, gibt es für den Aufraggeber nicht die Notwendigkeit das Projektteam zu steuern. Hierfür wird ein erfahrener Projektleiter auf der Seite des Auftragnehmers eingesetzt. Der Auftraggeber nimmt im Wesentlichen die Rolle des Produktmanagers ein, der die Roadmap definiert und verantwortet. Gemäß dem design2cost-Ansatz wird so versucht, das bestmögliche Ergebnis mit dem zur Verfügung stehendem System zu erziehen.

Das Vorgehen

Dem Kunden werden die Anforderungen kommuniziert. Hierbei stellt sich recht schnell heraus, welche Anforderungen dem Kunden besonders wichtig sind. Es entsteht also bereits hier eine entsprechende Priorisierung. Aus Erfahrungen von andern Projekten lässt sich der Aufwand der Anforderungen und somit die Kosten schätzen. Die Summe bestimmt das Budget. Bei Projekten, bei denen das Budget bereits vorher bekannt ist, hilft der Aufwand dazu, Anforderungen zu priorisieren. Sind die Prioritäten bekannt, kann das agile Festpreisprojekt beauftragt werden und starten.

 

Das agile Festpreisprojekt

 

Das Vorgehen im Projekt ist ein iterativer Prozess, der auch parallelisierbar ist. Mit 15% des Budges (für eine Anforderung) werden mögliche Lösungsansätze für diese entwickelt. Sollten sich die Lösungsansetze mit der Budgetschätzung deckeln, kommt es zur konkreten Planung, Implementierung und letztendlichen zum Release.

Übersteigt der Aufwand, die zuvor geplante Summe einer Anforderung, so muss diese entsprechend in der Roadmap angepasst werden. Idealerweise wird die Anforderung in verschiedene Teile aufgebaut, die feiner priorisiert werden. Damit lassen sich teile der Anforderungen streichen oder verschieben. Es kommt aber auch vor, dass der Aufwand viel geringer ist als die Schätzung. Auch das muss entsprechend in er Roadmap vermerkt werden und es können am Ende noch zusätzliche Anforderungen umgesetzt werden.

Sollten sich während des Projekts Anforderungen ergeben, die vorher nicht bedacht waren, jedoch hoch priorisiert werden, kann man diese durch einen „Feature-Tausch“ noch in das Projekt einbringen, ohne den Festpreis erhöhen zu müssen.

Fazit

Eine vertrauensvolle Kundenbeziehung und eine sehr gute Kommunikation sind zwingende Voraussetzungen. Wer dies allerdings gewährleisten kann, hat die Möglichkeit, Projekte früher als andere und mit einem optimaleren Ergebnis umzusetzen. In den meisten Fällen überwiegen diese Aspekte den zu erwartenden Mehraufwand und die intensive Kommunikation. Die Risiken werden durch eine gemeinsame professionelle Zusammenarbeit und dem Bewusstsein, das die Risiken gemeinsam getragen werden kontrollierbar.