This post in English

Auf den ersten Blick wirkt ein Agiles Festpreisprojekt wie ein unlösbarer Widerspruch. Festpreisprojekte bieten durch exakte Beschreibungen beiden Seiten Klarheit über die zu erbringenden Leistungen, Termine und Mitwirkungspflichten. Das Risiko trägt der Auftragnehmer – der Auftraggeber wiederum mitunter einen entsprechenden Aufschlag.

Der Begriff Agilität bedeutet beweglich, enthält also die Eigenschaft der Änderung. Agilität erlangt vor allem im Kontext der agilen Softwareentwicklung immer mehr Zuspruch: Weniger Bürokratie und mehr iterative Zyklen führen zu dem wirklich benötigten Ergebnis am Ende des Projektes.

Änderung im Festpreis – wie kann das gut gehen?

Wie viel Agilität braucht ein erfolgreiches Projekt denn wirklich?

Während die einen im Projektvorgehen strikt auf das Wasserfallmodell schwören, geht bei den anderen nichts ohne Scrum. Die Wahrheit liegt wie bei so vielem irgendwo dazwischen.  Zu den Erfolgsfaktoren eines Projektes gehören sehr viele Aspekte. Neben den üblichen Bekannten der Zielerreichung wie Termin, Budget und Leistung gehört zur Project Excellence auch die Ziel- und Kundenorientierung. Genau hier sind meistens die Ursachen zu finden für ein nicht komplett erfolgreiches Projekt: Es wird genau das erstellt, was am Anfang festgelegt und in einen Festpreis-Vertrag gegossen wird. Leider kann man das Ergebnis hinterher oft nicht gebrauchen, da sich die Ziele während der Projektlaufzeit geändert haben oder aber hätten ändern sollen, der Plan aber nicht angepasst wurde.

Viele größere Vorhaben auf Basis des Wasserfallmodells beginnen nie oder aber viel zu spät, da die benötigte Zeit zur exakten Spezifikation oft unterschätzt wird. Dabei möchte man eigentlich nur Unklarheiten und damit das Risiko für beide Seiten minimieren.

Agile Softwareentwicklung muss nicht auf einem Paradigma basieren

Agilität im Projekt entsteht ja schon dann, wenn zwei Hauptmerkmale berücksichtigt werden:

• Feature-Tausch – das Recht und die Möglichkeit ein ursprünglich geplantes Teil-Vorhaben zu reduzieren, zu erweitern, gänzlich zu streichen oder aber zu ersetzen
• Release whenever you want – Kleine Iterationen von etwa einem Monat ergeben eine frühzeitig einsatzbereite (Teil-)Funktionalität

Beide Merkmale ermöglichen eine optimale Ausrichtung an sich ändernde Projektziele und aktuelle Erfordernisse über eine längere Projektlaufzeit – und damit die Zielorientierung. Am Ende entsteht wirklich genau das, was in dem Moment gebraucht wird. Dies ist die Basis, schnell auf Marktänderungen zu reagieren: “time to market”

Die folgenden Aspekte helfen bei der agilen Softwareentwicklung:

• Sorgfältige Anforderungsanalyse – die Anwendungsszenarien definieren die Umsetzung in der Datenbank und nicht umgekehrt!
• Iteratives Vorgehen – Jede Funktionalität hat eine eigene Roadmap.
• Pareto-Prinzip – In der Spezifikation einer Funktionalität muss die technische Architektur und die Anwenderinteraktion zuerst stehen. Alle weiteren Details können im Laufe der Umsetzung konkretisiert werden.

Zu oft sind es die Unklarheiten am Anfang, die ein Risiko für Missverständnisse bergen. Ebenso ist ein agiles Vorgehen nur mit einer intensiveren Kommunikation zwischen Auftraggeber und Auftragnehmer tragfähig. Hier kommt es neben einem erhöhten Budget auch auf die gelebte Kommunikation an. Am Ende ist jedwede Änderung im Projekt im Änderungsmanagement festzuhalten und bedeutet auch einen erhöhten Aufwand.

Jeder Auftraggeber hat den Wunsch, das beste Ergebnis zu erhalten. Dabei wird leider zu oft versucht, das Risiko durch die Form eines niet-und-nagelfesten Vertrages zu minimieren und dabei die Chance vertan, Freiräume zu lassen, um am Ende doch genau das zu bekommen, was man eigentlich braucht. Der Teufelskreis, dass sehr oft am Anfang eines Projektes die Anforderungen noch nicht so klar sind, wird damit nicht durchbrochen. Ebenso wird durch das gegenseitige Absichern sehr viel Bürokratie geschafft, die bei eventuell doch auftretenden Änderungswünschen im Wege steht.

Wie passt das jetzt alles mit dem agilen Festpreisprojekt zusammen?

Die Basis für ein solides Projekt ist die ursprüngliche Aufwandsschätzung. Egal ob Top-Down oder aber Bottom-Up, mit Hilfe von Experten und entsprechenden Verfahren kommt man sehr schnell zu einer groben Budgetplanung, die mitnichten schon alle denkbaren sondern nur die wesentlichen Aspekte enthält. Das ist gewollt und vor allem auch Bestandteil des iterativen Vorgehens im Projekt. So gelangt man zu einem Rahmen für jede Funktionalität, an der sich der Lösungsweg dann orientieren soll. Ebenso lassen sich jetzt schon erste Kosten-Nutzen-Bewertungen durchführen, um zu entscheiden, ob der Weg zur Umsetzung überhaupt gegangen werden sollte.

Ein agiles Festpreisprojekt ist im Prinzip ein Vorgehen im gedeckelten Aufwand. Es gibt keine versteckten Risikoaufschläge, da ein beiderseitiges Bekenntnis zum gemeinsamen Tragen des Risikos besteht. Ebenso gibt es keine Notwendigkeit für den Auftraggeber, das Projektteam zu steuern, da hierfür ein entsprechend erfahrener Projektleiter auf der Seite des Auftragnehmers zur Verfügung steht. Der Auftraggeber nimmt im wesentlichen die Rolle des Produkt-Managers ein, der die Roadmap definiert und verantwortet. Der Projektleiter arbeitet mit dem Produktmanager zusammen und unterstützt dabei einen ganz bedeutsamen und entscheidenden Prozess in der Umsetzung. Gemäß dem design2cost-Ansatz entwickelt er mögliche Lösungswege und Ausbaustufen einer Funktionalität, um mit dem vorhandenen Budget das optimal mögliche Resultat zu erzielen.

Das Vorgehen

Die Anforderungen werden idealerweise in Stories formuliert, die den zukünftigen Kunden erzählt werden. Dabei erkennt man recht schnell welchen Nutzen diese Story transportiert und damit können dann auch schon Prioritäten definiert werden. Aus Erfahrungen oder Kenngrößen aus vergleichbaren Projekten lassen sich grobe Volumina des vermuteten Aufwandes ermitteln. Die Summe bestimmt das Budget. Sollte das Budget vorher bekannt sein, können die voraussichtlichen Aufwände für die Stories auch anhand dieser Summe verteilt werden. Sind die Stories, deren Prioritäten und das Volumen (Budget) bekannt, kann das Agile Festpreisprojekt beauftragt werden und starten.

Das Vorgehen im Projekt ist ein iterativer Prozess, der auch parallelisierbar ist. Der Start ist die Wahl der nächsten Story und eine sich anschließende Analyse/Design-Phase. Mit etwa 15% des veranschlagten Budgets der Story werden Lösungsmöglichkeiten formuliert. Mit diesen Details lässt sich der Aufwand genauer abschätzen als noch zum Anfang. Sollte die Schätzung noch passen, kann die konkrete Planung und Implementierung starten, die in einem Release endet.

Sollte der Aufwand nicht passen, so wird die aktuell geplante Roadmap des Festpreisprojektes angepasst. Idealerweise ist die Story in mehreren Teilen aufgebaut, die entsprechend feiner priorisiert werden. Damit lassen sich Teile der einen oder anderen Story streichen oder aber (auf später) verschieben. Manchmal ergibt eine Schätzung aber auch, dass der Aufwand viel geringer als geplant ist. Hier wird dann neben der Umsetzung auch die Roadmap angepasst. Es lassen sich mehr Stories umsetzen.

Während der Laufzeit des Projektes kommen neue Ideen auf und der Kunde wünscht sich ein neues Feature, was beim Start noch nicht bedacht wurde, aber aus heutiger Marktsicht hoch priorisiert wird. In diesem Falle wird wie zum Anfang eine grobe Hausnummer des Aufwandes abgeschätzt und anhand des Nutzens auch ein Budget definiert. Am Ende kann diese Story über die Anpassung der Roadmap in den beauftragten Festpreis gelangen. Das Vorgehen wird dann oft als Feature-Tausch bezeichnet.

Fazit

Nur eine vertrauensvolle Kundenbeziehung bietet die Grundlage für ein agileres Vorgehen im Projekt. Die Chance, früher als andere ein optimales Projektergebnis zu erzielen, überwiegt etwaige Mehraufwände durch intensivere Kommunikation. Die Risiken werden durch eine gemeinsame professionelle Zusammenarbeit und dem Bewusstsein, das Risiko gemeinsam zu tragen, kontrollierbar.

Wir und unsere Kunden haben viele gute Erfahrungen mit agilen Festpreisprojekten bis zu Größenordnungen von 1000PT gemacht. Dabei können die zertifizierten Projektleiter (IPMA) auf ein sehr erfahrenes Team von Usability Experten zurückgreifen, die gerade am Anfang des Projektes dabei helfen, die Bedürfnisse der Anwender zu analysieren und während der Projektlaufzeit regelmäßig mit Akzeptanztests zu auditieren. Bei der Beurteilung der Lösungswege und der Tragfähigkeit der Zielarchitektur bauen die Projektleiter auf unsere zahlreichen zertifizierten Java-Experten. Eine ausgeklügelte standardisierte Entwicklungsinfrastruktur ermöglicht nicht nur eine bestmögliche Testabdeckung sondern auch kurze Release-Zyklen.

 

Tassilo Kubitz

akquinet tech@spree

(Mitglied der GPM-Fachgruppe Agile Management)