Agile Contracts – Wie gestaltet man Verträge für agile BI-Vorhaben?

Nicht nur die Fach- und IT-Abteilungen sind in der Umsetzung der Business Intelligence-Projekte mit neuen agilen Methoden konfrontiert, sondern auch die Einkaufsabteilungen der Kunden sowie die Verkaufsabteilung der Dienstleister müssen sich dementsprechend anpassen. Aber was genau kommt nun auf den Ein- und Verkäufer zu, wenn ein iteratives, inkrementelles Vorgehen für das Projekt gewählt wurde? Und wie viel Verständnis hinsichtlich der veränderten Umstände benötigen wir dazu aus dem Management? Im heutigen Beitrag beschreibe ich die Sicht des Verkäufers.

Bisheriges Wasserfall-Modell

Das klassische Wasserfall-Modell bringt Vor- aber auch Nachteile mit sich. Als Grundlage für einen Vertrag bilden konkrete Spezifikationen, definierte Lieferobjekte und ein vereinbarter Zeitplan zum zu verhandelnden Budget für Einkäufer und Verkäufer eine greifbare Verhandlungsmasse. Das Projekt kann auf Basis dieser Grundlagen meist in verschiedene Phasen mit definiertem Start- und Endzeitpunkt unterteilt werden. Der Kunde erhält die Sicherheit zu wissen, welche konkret definierten Lieferobjekte pro Phase fertiggestellt werden und wie viel diese kosten. Je nachdem können verschiedene Verträge, wie z. B. Werkverträge mit Fixpreis, Time & Material mit Kostendach, dafür vereinbart werden. Dabei bekommen Werkverträge meist einen mittleren bis hohen Risikozuschlag oder werden mit sehr strikten Change Request-Prozessen bestückt. Oft befindet sich dadurch der Kunde in einer Schein-Sicherheit bezüglich der Einhaltung von Budget und Zeitplan. Eine Änderung im Vorgehen und bei den Verträgen wäre somit notwendig, um auf die Realität von sich ändernden Anforderungen besser eingehen zu können.

Iteratives, inkrementelles Vorgehen

Die Änderungen der Spezifikationen bzw. das Identifizieren der richtigen Spezifikationen in Zusammenarbeit mit dem Fach (Product Owner) ist der Schlüssel zum Erfolg. Die traditionellen Projektvorgehen und Ihre dazugehörigen Verträge sind meist zu starr, zu unflexibel, um auf Änderungen während des Projektes einzugehen. Das Vorgehen muss also die zeitnahe und enge Abstimmung zwischen dem Fach und der IT bzw. dem externen Dienstleister gewährleisten können. Die gemeinsame Definition über das Lieferobjekt der ersten Projektiteration geschieht somit nicht vor den Vertragsverhandlungen, sondern erst nachdem das Team zusammengestellt und das Projekt gestartet ist. Viele Unternehmen haben sich bereits heute neu orientiert und arbeiten mit Vorgehensmodellen, wie z. B. SCRUM oder Disciplined Agile 2.0, um IT- und BI-Projekte nach den Grundsätzen der Transparenz, der Überprüfung und der kontinuierlichen Anpassung umzusetzen. Dabei gilt, dass pro Iteration ein fertiges, benutzbares Teilprodukt an den Kunden geliefert wird. Die Erkenntnisse aus dieser Iteration fliessen wiederum in die nächste Iteration, auch Sprint genannt, ein. Die Zusammenarbeit basiert auf Offenheit und Vertrauen und sollte beidseitig bei Unzufriedenheit beendet werden können. Aber welche Auswirkungen hat dies nun auf den dazugehörigen Vertrag?

Verträge für agile Vorhaben

Dies bedeutet folgende Grundlage für die Verträge. Es besteht im Vorfeld zwar eine Projektvision und eine gewisse Vorstellung, welche Fachanforderungen umgesetzt werden müssen, allerdings liegen keine Detailspezifizierungen vor, die eine realistische Aufwandsschätzung ermöglichen. Der Auftraggeber geht davon aus, dass sich Anforderungen während der Projektlaufzeit erst herauskristallisieren werden bzw. sich nochmals ändern könnten. Das Lieferobjekt lässt sich somit im Vorfeld nicht detailliert genug spezifizieren und somit auch nicht für den Vertrag fixieren.

Wie gehen wir also vor? Mit welchem Vertrag können wir das gemeinsame noch festzulegende Ziel erreichen?

Wie so oft, können diese Fragen nur mit „das kommt darauf an“ beantwortet werden. Grund dafür sind die verschiedenen Situationen, in denen sich der Verkäufer befindet.

• Bestandskunde mit etablierter Vertrauensbasis
  Zwischen den Parteien besteht bereits ein Vertrauensverhältnis und Qualitätsversprechen. Der Verkäufer bietet ein Expertenteam für das Business Intelligence- bzw. Data Warehouse-Projekt auf Basis Time & Material (T&M) an. Je nachdem wird von Iteration zu Iteration beauftragt oder aber eine Anzahl Iterationen wird auf Basis des verfügbaren Budgets festgelegt. Auf Seiten des Kunden wird ein Product Owner definiert, der die Rahmenbedingungen sowie den Scope bestimmt und extern aber auch intern vertritt. Auf Bonus-Malus-Regelungen wird meist auf Basis der etablierten Zusammenarbeit und dem Vertrauensverhältnis verzichtet. Allfällige Mehraufwände werden partnerschaftlich geteilt. Ein Risk-Share kann als Rahmenbedingung formuliert werden.

• Kunde mit ersten Erfahrungen
  Zwischen den Parteien bestehen erste Geschäftsbeziehungen. Auch hier bietet der Verkäufer ein Expertenteam für das Business Intelligence- bzw. Data Warehouse-Projekt auf Basis T&M an. Beauftragungen von Iteration zu Iteration mit beidseitiger Möglichkeit des Ausstiegs sind denkbar. Der Kunde stellt einen Product Owner, der die Rahmenbedingungen und den Scope bestimmt und vertritt. Eine klare Bonus-Malus-Regelung wird in den Rahmenbedingungen festgehalten, um bei Unzufriedenheit dem Kunden eine Reduktionsmöglichkeit als Sicherheit zu bieten. Allfällige Mehraufwände werden in Form eines Riskshares in den Rahmenbedingungen formuliert. Der Dienstleister trägt ein gewisses Risiko, um sein Lieferungs- und Leistungsversprechen zu bestätigen. Beim Einhalten des Versprechens wird er mit weiteren Iterationen belohnt.

• Interessenten im Angebotsverfahren mit Konkurrenten
  Dienstleister und potenzieller Kunde haben noch keine Geschäftsbeziehung. Gemeinsame Eindrücke wurden bisher nur auf Basis von Telefonaten, Treffen, Homepagebesuchen und ausgetauschten Referenzen gesammelt. Es besteht somit nur ein erstes positives Gefühl, aber noch kein etabliertes Vertrauensverhältnis. Folgende zwei Arten der Anfrage sind denkbar:
•      Anfrage mit Bezug auf eine agile Vorgehensweise
  Bei Interessenten mit einer Anfrage, die eine agile Vorgehensweise wünschen, können je nach Sicherheitsempfinden eine Bonus-Malus-Regelung und andere Rahmenbedingungen, wie z.B. Risk-Share, vereinbart werden. Dies entspricht der zweiten Ausführung „Kunde mit ersten Erfahrungen“.
•     Anfrage ohne Bezug auf eine agile Vorgehensweise
  Bei Anfrage ohne Bezug ist dagegen eine Einigung nur möglich, wenn im Angebotsverfahren der Kunde vom agilen Vorgehen überzeugt werden kann oder zumindest Angebote für beide Formen oder Mischformen akzeptiert werden. Hier zeigt (unsere) meine Erfahrung, dass sich das Management, die Fachabteilung und der Einkauf ausdrücklich dafür aussprechen müssen, da sonst bei der Vergabe Äpfel und Birnen miteinander verglichen werden.  

Fazit

Mehr Agilität in BI- und DWH-Projekten bringen Fach und IT näher zusammen und beschleunigen den „Time-to-Business Value“-Prozess und sollten deshalb verfolgt werden. Es benötigt dazu aber nicht nur fähige Personen des Kunden und des Dienstleisters, sondern auch die notwendige Management-Unterstützung, die bewusst auf Schein-Sicherheit verzichtet und andere Formen von Verträgen begrüsst. Dabei ist es aus meiner Sicht unerlässlich, dass der Product Owner für das Projekt die notwendigen Kompetenzen übertragen bekommt und die Verantwortung für das Projekt übernimmt. Nur unter diesen Voraussetzungen kann das Vertrauensverhältnis zwischen Auftraggeber und Lieferant aufgebaut werden, um in Zukunft agile Projekte auf Basis agiler Verträge (T&M + Rahmenbedingungen) umzusetzen.