Ein erfolgreiches Softwareprojekt hält nicht nur Zeit und Kosten ein. Die bereitgestellte Lösung soll von Benutzern akzeptiert werden und einen großen Mehrwert bringen. Kommt Ihnen dieser Wunsch bekannt vor?
Anders beschrieben – agil vorgehen, aber bitte zu einem fixierten Preis. Damit stellt sich unweigerlich die Frage: Wie soll das Ganze funktionieren? Ein Vertrag mit einem Festpreis braucht genaue Definitionen, was geliefert werden muss. Die Tendenz zu vielen Seiten an Spezifikation steigt, die aber spätestens nach wenigen Monaten Umsetzung in einem Softwareprojekt überholt sind. Ohne genaue Anforderungen fühlt sich ein Vertrag wiederum eher wie ein Blanko-Scheck, mit nie endendem Aufwand, an.
Es gibt ein paar Punkte, die eine wichtige Rolle bei agilen Fixpreis-Projekten spielen. Um vorzugreifen – ja, agile Fixpreis-Projekte sind möglich!
Vertrauen als Basis
Egal wie viel in einem Vertrag steht, am Ende arbeiten Menschen zusammen. Wenn die Zusammenarbeit nicht funktioniert, wird das Ergebnis auch keine Spezifikation in einem Vertrag retten. Durch einen Fixpreis wird nicht automatisch das Risiko reduziert. Im Gegenteil, es kann in mühsamen Change Requests und Diskussionen über kleine Änderungen enden.
Die Grundlage ist offene Kommunikation vom ersten Gespräch an. Wenn Kunde und Anbieter nicht transparent über Vorgehen, Hintergründe und Ziele sprechen können, sollten auch keine gemeinsamen Projekte gestartet werden. Eine Möglichkeit ist auch, mit kleinen Projekten zu starten, um so Vertrauen aufzubauen, sehen ob Ideen übereinstimmen und kontinuierlich Fortschritt sichtbar ist. Danach Projektteams auf die Bedürfnisse anpassen, um so große Lösungen gemeinsam zu entwickeln.
Kostendeckel und einfacher Tausch
Das agile Fixpreis-Projekt braucht ausreichend Flexibilität, um auf Probleme und Änderungen einzugehen. Das soll keine Freikarte für endloses Budget sein. Mit einem Kostendeckel wird eine Obergrenze vereinbart. Innerhalb dieser Grenze wird zuerst eine solide Basis mit den Kernfunktionalitäten entwickelt. Damit garantiert ein Anbieter, dass das grundlegende Problem gelöst wird. Anschließende Funktionalitäten werden transparent geschätzt und offen diskutiert. So kann jederzeit ein Funktionsblock gegen einen Anderen in der Priorität getauscht oder gar weggelassen werden, falls ein Funktionsblock nicht mehr relevant ist.
Die Herausforderung liegt in der strukturierten Vorgehensweise. Fokus auf die kritischen Funktionalitäten am Anfang ist leichter gesagt als getan. Dazu gehört ebenso, Funktionalitäten abzulehnen, auch wenn sie in dem Moment sehr nützlich erscheinen. Am Ende soll eine faire Lösung für beide Seiten – Kunde und Anbieter – herauskommen.
Es kommt auf das Bedürfnis an
Ein Projekterfolg definiert jeder anders. Daher ist es wichtig, die Erwartungen abzuklären und klar zu definieren, was mit dem Projekt erreicht werden soll. Damit wird festgelegt, welchen Mehrwert die bereitgestellte Software bringt, statt zu definieren, wie die Lösung aussieht.
Bei einem Bedürfnis schnell von A nach B zu gelangen, benötigt es keine Spezifikation über die Farbe des Autos. Nicht einmal, dass es ein Auto sein soll. Wenn das Bedürfnis, welches gelöst werden soll, fixiert ist, gilt es, schnell eine erste Version der Lösung des Problems zu entwickeln. Danach kann laufend weiter optimiert werden. Nur so kann auf Feedback und Änderungen im Laufe der Entwicklungszeit eingegangen werden. Am Ende kommt eventuell ein Motorboot raus, welches die Bedürfnisse der Benutzer viel besser abdeckt als das ursprünglich angenommene Auto.
Resultat: Fixer Preis, agiler Weg
Ein agiles Fixpreis-Projekt ist kein Widerspruch und funktioniert sehr gut, wenn sich Kunde und Anbieter an gewisse Spielregeln halten. Ein Preis ist als Obergrenze fixiert. Der Anbieter kommuniziert transparent Aufwände und Schätzungen von Funktionalitäten, sodass im gesetzten Rahmen das Projekt erfolgreich umgesetzt werden kann. Funktionalitäten, welche nicht zum gesetzten Ziel beitragen, werden auf spätere Projekte verschoben.
Im Vertrag wird definiert, welches Problem bzw. welches Bedürfnis gelöst wird. Pflichtkriterien werden als Ziele fürs Umsetzungsprojekt definiert. Wie die Lösung umgesetzt wird, wird laufend erarbeitet und basierend auf Feedback kontinuierlich optimiert.