Website-Icon akquinet AG – Blog

Wie steuere ich den Agilen Festpreis?

In meinen Projekten geht es meistens um individuelle Softwareentwicklung. Das fehlende Puzzlestück im Geschäftsmodell selber zu erstellen kann oft kostengünstiger sein, als eine Standardlösung mit Konfigurationsaufwand und laufenden Lizenzkosten. Die Projekte sind dabei so vielfältig wie die Branchen es sein können. Der Schwerpunkt meiner Erfahrung liegt bei den klassisch denkenden Auftraggebern, die sich mit viel Tradition im Gepäck den Herausforderungen des heutigen Marktes stellen müssen.

Auch bei vielen traditionsreichen Unternehmen setzt sich vermehrt die Erkenntnis durch, dass Agiles Projektvorgehen viele Vorteile mit sich bringt und nicht mehr per se infrage gestellt wird.

So habe ich in zahlreichen Diskussionen mit Projektleitern und Entscheidern über das hybride Projektvorgehen „Agiler Festpreis“ (1) gesprochen und ihnen die Vorteile (2) erläutert. Es war nicht schwer, sie von dem iterativen Vorgehen und der engen Zusammenarbeit mit Anwendern zu überzeugen.

Die größten Schwierigkeiten entstanden bei dem Verständnis der Projektsteuerung.

Verzichten? Nein Danke!

Aus dem Leistungsdreieck kann abgeleitet werden, wann welches Vorgehen und welche Steuerung passender ist (3).

Mehr Budget zu beantragen oder den Termin zu verschieben war aus deren Erfahrung gewohnter, als der andere Weg, den Scope zu ändern. Dabei muss man doch nur Dinge weglassen können.

Aber welche?

Das Optimum herausholen

Unser hybrides Vorgehensmodell „Agiler Festpreis“ soll zwei Dinge in einem Projekt für den Auftraggeber erreichbar machen:

Am Ende des Budgets sind die Projektergebnisse fertig, nutzbar und bringen den maximal erreichbaren Nutzen. Das Geld ist also optimal investiert.

Die Herausforderung besteht nun also darin, das Projekt so aufzusetzen, dass man

Das Setting macht’s

Auch auf Basis eines klassischen Wasserfall-Projektes kann eine Entkoppelung vorgenommen werden. Unter Berücksichtung der technischen Abhängigkeiten zwischen den Anforderungen und dem Bedarf des Marktes lassen sich große Projekte in viele Teilprojekte zerlegen.

Das folgende Beispiel zeigt die Parallelisierung des Wasserfalls in mehrere Features, die durchaus als Iterationsschleifen (bzw. Sprints) verstanden werden können.

Im Ergebnis wird nicht nur der Release-Termin vorgezogen, sondern auch entschieden welches Feature zuerst umgesetzt werden soll. Das time2market wird steuerbar (4). Einen Schritt weitergedacht, lässt sich damit auch das Budget steuern: Lässt man ein Feature weg, reduzieren sich die Kosten.

Der Ansatz lässt sich mittels design2cost (2) auch auf den Umfang eines Features anwenden. Dann werden die Anforderungen innerhalb des Features Muss, Soll und Kann unterteilt. Bei Bedarf wird auf die Kann-Funktionen eines größeren Features verzichtet.

Wie treffe ich eine Entscheidung?

In jedem Projekt sollte es darauf ankommen, das Richtige umzusetzen und das weniger Wichtige sein zu lassen. Unabhängig von agilem oder klassischem Projektvorgehen.

Damit nähern wir uns dem Hauptproblem.

Meine Ansprechpartner haben durchaus das Verständnis dafür, dass man etwas weglassen muss. Sie haben aber Schwierigkeiten dabei, die Anforderung zu finden, die man in der aktuellen Situation weglassen sollte. Darüber hinaus muss diese Entscheidung ja auch kommuniziert und dem Top-Management verständlich erklärt werden.

Die Lösung für dieses Problem verbirgt sich in der Betrachtung des Nutzens einer Anforderung.

Kenne ich den Nutzen, dann kann ich alle Anforderungen gegen deren Kosten abwägen und setze nur die um, die in einem gewählten Budget den Nutzen maximieren. Die Berechnung des Nutzens ist allerdings nicht so leicht. Dennoch gibt es einen sehr guten Ansatz, den ich in dem Artikel „Von der Impact Map zu User-Storys: Wie Stakeholder und Entwickler gemeinsam eine Strategie verfolgen“ von Dr. Monika Schubert (5) gefunden habe.

Im Grunde genommen geht es darum, die vielen kleinen Anforderungen in Form von User Stories so zu strukturieren, dass man in der Lage ist, nur das feiner auszuarbeiten und später umzusetzen, was am meisten Nutzen bringt.

Mit Hilfe dieser Struktur lassen sich Roadmaps erstellen, deren Inhalte den größten Nutzen erzielen. Ein passender Schnitt verlagert Funktionen mit aktuell weniger Wirkung in ein späteres Release.

Viele positive Erfahrungen

Während des letzten Jahres habe ich mit dieser Strukturierung gearbeitet und mehr positive Erfahrungen gemacht, als ich zuerst dachte:

Fazit

Die Steuerung des Agilen Festpreis ist möglich, wenn man die richtigen Dinge weglässt oder hinzunimmt. Dabei helfen die geeignete Kombination der Methoden Impact Map, Story Map und User Story.

In der Summe wird damit nicht nur der Sinn und Zweck einer User Story für den Entwickler transparenter, sondern vielmehr auch eine transparente Entscheidung möglich, was man innerhalb eines Budgets umsetzen sollte und was nicht.

Das Weglassen fällt leicher.

Tassilo Kubitz

 

Quellen:

(1) akquinet AG – Agile Festpreisprojekte – akquinet.de

(2) Tassilo Kubitz – Agile Festpreisprojekte – Risiko oder Chance? – blog-de.akquinet.de 29.04.2014

(3) Atlassian –  The iron triangle of planning

(4) Tassilo Kubitz – Agile Roadmaps in der Softwareentwicklung – blog-de.akquinet.de 08.10.2014

(5) Dr. Monika Schubert (Opitz Consulting) – Von der Impact Map zu User-Storys: Wie Stakeholder und Entwickler gemeinsam eine Strategie verfolgen – OBJEKTspektrum 02/2016 (Seite 20-25)

(6) Tassilo Kubitz – Von der Lösung zum Problem – Impact Mapping mal anders herum – blog-de.akquinet.de 08.10.2014

Die mobile Version verlassen