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