Bei einer gemeinsamen Unternehmung zweier oder mehrerer Firmen, wie z.B. einem Kundenprojekt, wissen die Beteiligten zu Beginn oft noch nicht, wie sich ihre Zusammenarbeit genau gestalten wird. Der Vertrag, auf dem diese beruhen soll, braucht deshalb ein hohes Maß an Offenheit. Verschärft gilt dieses als "incomplete contracts" bekannte Konzept für agile Projekte, weil bei ihnen das Ziel nicht genau definiert ist und häufige Änderungen den Projektverlauf prägen. Auftragnehmer sollten bei agilen Projekten in der Vertragsgestaltung daher einiges beachten, wie folgendes Beispiel zeigt.

Ein Unternehmen beauftragte ein anderes, ihm dabei zu helfen, neue gesetzliche Vorschriften termingerecht zu erfüllen. Als vertragliche Basis für die Zusammenarbeit vereinbarten Kunde und Auftragnehmer einen Festpreisvertrag über die Gesamtlaufzeit des Projekts. Zudem einigten sie sich darauf, agile Praktiken anzuwenden. Während des Projektverlaufs gab es vom Kunden häufig wechselnde Anforderungen und Änderungswünsche, sodass der Auftragnehmer befürchtete, seine Arbeit nicht mehr kostendeckend und fristgerecht zu Ende führen zu können. Als er dies kommunizierte, verwies der Kunde auf das Agile Manifest und pochte auf den Grundsatz, dass bei der Anwendung agiler Methoden häufige Änderungswünsche doch begrüßt werden sollten.

Erst durch den Hinweis, dass er durch seine vielen Änderungswünsche die Deadline gefährdete, konnte der Auftragnehmer seinen Kunden überzeugen. So erkannte der Zulieferer, welch starkes Instrument eine solche Terminfrist sein kann, besonders wenn es im Interesse des Kunden liegt, diese einzuhalten. So konnte das Projekt schlussendlich doch noch zu einem guten Abschluss gebracht werden.

Das Beispiel verdeutlicht eine große Herausforderung für agile Projekte: Das Ziel ist oft noch nicht genau definiert und häufige Änderungen prägen den Projektverlauf. Wie der Kunde im Beispiel richtig herausstellte, sind Agile Praktiken dafür gedacht, die nötige Flexibilität für einen offenen, gar begrüßenden Umgang mit diesen Änderungen zu schaffen. Trotz aller Offenheit für das Unbekannte müssen Kundenprojekte, die mit agilen Methoden durchgeführt werden, immer von Vertragswerk begleitet sein. Dabei kann das eingangs beschriebene Spannungsfeld entstehen, das alle Beteiligte immer im Blick haben sollten.

Das Agile Manifest setzt die Priorität: "We […] value customer collaboration over contract negotiation" (siehe agilemanifesto.org). Wie bei allen Statuten des Manifests bedeutet dies nicht, dass schriftliche Verträge nicht gewünscht oder unnötig wären – lediglich sollten sie einer fruchtbaren Zusammenarbeit nicht im Weg stehen.

Die Absicht hinter der Formulierung durch die Autoren des Manifests war zudem sicher nicht, Firmen, die agile Methoden einsetzen, möglichst häufig vor Gericht enden zu lassen. Bei den meisten agilen Rahmenwerken wie Scrum geht es vielmehr darum, für alle Beteiligten von vornherein vorteilhafte Bedingungen zu schaffen: Gutwilligkeit auf beiden Seiten, ein Höchstmaß an Respekt für und Vertrauen in alle, die am Projekt mitarbeiten, möglichst nahe räumliche Zusammenführung dieser Zusammenarbeitenden, Transparenz und Anpassungsfähigkeit sowie enger Austausch mit Kunden und Endnutzern des zu erschaffenden Produkts – bekannt als das "Agile Mindset". Wer all dies genauso umsetzt, ist nahe an einem Idealzustand, der es eher unwahrscheinlich macht, dass Vertragsstreitigkeiten überhaupt erst entstehen. Die Praxis sieht jedoch manchmal anders aus.

Festpreisvertrag als rotes Tuch für Agile?

Deshalb ist bei der Wahl des Vertragstyps Vorsicht geboten. Für agile Projekte ist ein Festpreisvertrag über das Gesamtprojekt aus bereits genannten Gründen sehr wahrscheinlich ungeeignet. Denn dort liegt das Kostenrisiko allein beim Lieferanten. Das hat in der Regel auch negative Auswirkungen für den Kunden: Um sich gegen zu häufige Änderungen zu schützen, lässt der Lieferant deutlich weniger Freiraum für Änderungswünsche.

Sie fragen sich jetzt sicher: Welche Vertragstypen eignen sich denn für ein agiles Projekt? Ich habe häufig von Firmen gehört, die durchaus Festpreisverträge einsetzen. Allerdings vereinbaren sie pro Iteration einen Einzelpreisvertrag (engl. Unit Price) – statt für das Gesamtprojekt. Dass die Kosten für jede Iteration festgelegt werden, erscheint angesichts der inkrementell-iterativen und von enger Zusammenarbeit geprägter Natur agiler Projekte sinnvoll.

Folgende Kriterien sollten dabei schriftlich festgehalten werden: (angeregt durch Arbogast et al.: "Agile Contracts Primer", 2012, S. 20)

Dauer (üblicherweise zwischen zwei und vier Wochen) und evtl. Anzahl der Iterationen

Definition of Done: Übereinkunft über den Grad der Fertigstellung und potentiellem Auslieferzustand

Timeboxing: Die Dauer der Iterationen ist begrenzt, nicht aber der Leistungsumfang des Projekts

Indefinite Delivery, Indefinite Quantity

Ein weiterer, besonders im Verwaltungsbereich der USA sich verbreitender Vertragstyp ist "Indefinite Delivery, Indefinite Quantity" (IDIQ), dort vor allem unter der Bezeichnung "Blanket Purchase Agreement" gekannt. Dabei handelt es sich um eine zeitlich befristete, offene Rahmenvereinbarung, bei der Anzahl der Lieferabrufe und Umfang zum Abschlusszeitpunkt nicht feststehen. Diese Verträge sind "hybrid", weil sie Elemente aus Time & Material sowie Kostenerstattungsverträgen beinhalten.

Darüber hinaus sind Typen wie Zielkostenverträge gut denkbar – wobei gerade bei diesen wichtig ist, dass Risiken und Vorteile unter den Vertragspartnern so verteilt sind, dass die Freiräume der Vertragspartner mit den Zeit- und Kostenrisiken verbunden sind. Dies bedeutet vor allem, dass ein Kunde, der im Projektverlauf Offenheit für Änderungen und Scope-Erweiterungen haben möchte, die damit verbundenen Kosten übernimmt – dass er also ins Kostenrisiko des Projektes mit einsteigt. Eine partnerschaftliche Zusammenarbeit bedeutet auch einen partnerschaftlichen Umgang mit Risiken.

Alle Links wurden zuletzt am 05.10.2017 geprüft.

Lesen Sie zum Thema auch den Blogbeitrag "PM-FAQs: Welche Vertragsart passt zu meinem Projekt?"