legal lessons learned

Ueli Grüter, LL.M., Rechtsanwalt, Dozent Hochschule Luzern*

Elbphilharmonie Hamburg – Ein agiles Projekt, das mehrmals aus dem Ruder zu laufen drohte und vor Gericht landete.

Rollende Planung für flexible Produktentwicklung

Auch wenn sich die Verantwortlichen der Sache oft nicht bewusst sind, werden immer mehr digitale Projekte «agil» organisiert, wobei die Übergänge von «fix» zu «agil» oft fliessend sind. Das bedeutet vereinfacht, dass die kooperierenden Partner kein fixes Produkt, sondern den Prozess der Entwicklung, also eine rollende Planung definieren. Das Projekt wird in viele kleine, einander folgende Teilprojekte aufgeteilt; auch «Sprints» genannt. Dabei spielen eine enge Kooperation und Kommunikation der Partner eine wichtige Rolle. Teilresultate der Entwicklung kommen laufend in den produktiven Einsatz, werden laufend getestet. Ziel ist eine schnelle, flexible Produkteentwicklung. Agile Projekte sind nicht auf die Informatik beschränkt, sondern kommen auch in anderen Bereichen zur Anwendung, wie z.B. in der Architektur. So hatte das Schweizer Architekturbüro Herzog & de Meuron zwar eine Vorstellung davon, wie einst das Konzerthaus «Elbphilharmonie» in Hamburg aussehen sollte, das Projekt wurde aber vor dem Baustart nicht durchgeplant, sondern laufend entwickelt. Wie heikel eine solch agiles Vorgehen ist, zeigt denn auch exemplarisch der Bau der Elbphilharmonie, der neben extremen Verzögerungen auch mehrmals aus dem Ruder zu laufen drohte und vor Gericht landete. Der Volksmund kommentierte: Es arbeiteten mehr Anwälte als Architekten an dem Projekt (NZZ Online 18.04.2020). Genau dies gilt es aber unbedingt zu verhindern.

Juristische Problemfelder bei agilen Projekten

Auch wenn es Juristinnen und Juristen lieber wäre, ihre Unternehmen und Klienten würden ihre Projekte fix und nicht agil planen, müssen sie sich als Dienstleister den Umständen anpassen. Dafür ist es wichtig die Problemfelder agiler Projekte zu kennen.

In der Praxis habe ich festgestellt, dass sich die Projektpartner oft der agilen Projekte nicht bzw. nicht wirklich bewusst sind. Damit ist ihnen regelmässig auch die praktische, schon gar nicht die juristische Problematik klar.

Geradezu systemimmanent ist es, dass sich die Partner von agilen Projekten vertraglich nicht auf ein bestimmtes Resultat festnageln wollen. Dienstleistungen und angestrebte Resultate werden typischerweise nicht oder unklar definiert.

In einem fixen Projekt wird in der Regel ein Auftrag erteilt, wobei der Auftragnehmer diesen eigenständig ausführt und abliefert. In agilen Projekten dagegen arbeiten Auftragnehmer und Auftraggeber, soweit man diese als solche überhaupt noch abgrenzen kann, eng zusammen und damit überschneiden und verwischen sich oft die Verantwortlichkeiten.

Die enge personelle Kooperation kann darüber hinaus auch zu unklaren arbeitsrechtlichen Verhältnissen führen, insbesondere zum Personalverleih, der unter bestimmten Bedingungen sogar bewilligungspflichtig ist; mit Straffolgen bei Missachtung.

Rollend geplant werden nicht nur die agilen Projekte an sich, sondern auch deren Finanzierung. Spätestens wenn diese aus dem Ruder läuft, kommts zum Knatsch. Beim Beschluss des Baus der Elbphilharmonie durch den Senat von Hamburg im Jahre 2007 ging dieser von Gesamtkosten von rund 240 Millionen Euro aus. Bei der Eröffnung der Elbphilharmonie im Jahre 2017 sind die Koste auf rund 860 Millionen Euro angestiegen (sic!).

Hotspots eines Vertrages für agile Projekte

Auch wenn die Anlage bei agilen Projekten aus juristischer Sicht schwierig ist, lassen sich aus den genannten Problemfeldern Hotspots für die Vertragsgestaltung ableiten, mit denen juristische Auseinandersetzung wenn nicht verhindert, dann doch vermindert und in geordneten Bahnen bewältigt werden können.

Gleich zu Beginn des Vertrages sollten sich die Partner die Projektmethode bestimmen.

Auch wenn es zur DNA eines agilen Vertrages gehört, dass die Projektziele laufend entwickelt und ergänzt werden, sollte versucht werden im Vertrag ein mindestens übergeordnetes, wenn auch wenig konkretes Projektziel zu beschreiben.

Es folgt die die Definition der Projektorganisation und der Projektführung. Dabei geht es u.a. auch um die Frage, wer welche Rolle im Projekt übernimmt; bei der Projektmethode «Scrum» z.B. wer Product Owner ist, wer zum Entwicklungsteam gehört und wer die Rolle des Scrum Masters übernimmt.

Da eine enge Zusammenarbeit und Kommunikation der Projektpartner wesentliche Elemente eines agilen Projekts sind, ist es wichtig, dass im Vertrag klar definiert wird, wer von den jeweiligen Projektpartner mit wem von der jeweils anderen Projektpartnern wie zusammenarbeitet und kommuniziert. Dazu gehört auch die Mitwirkungspflicht des Auftraggebers, falls ein solcher in dieser herkömmlichen Art effektiv existiert.

In agilen Projekten beobachte ich ein «Management by E-Mail». Es fehlen klare, übersichtliche Protokolle und Reports, nach denen u.a. Pendenzen systematisch abgearbeitet und wiederum protokolliert und rapportiert werden. Zudem fehlt beim flexiblen und schnellen Entwickeln offenbar auch die Zeit für Dokumentationen. Solch oberflächliches Handeln macht es später insbesondere für Dritte schwierig bis unmöglich, Projektschritte, Projektänderungen und Projektresultate nachzuvollziehen und zu verstehen.

In den Vereinbarungen betreffend Projektorganisation, Projektführung, Zusammenarbeit und Kommunikation muss eine klare Abgrenzung der Verantwortlichkeiten enthalten sein, die es später ermöglicht, zu eruieren, wer für Mängel und allfällige Schäden haftet.

Auch bei einer flexiblen und schnellen Projektentwicklung dürfen Abnahmen nicht fehlen. Immer wieder kann man beobachten, dass mangelhafte Projekt-Teilresultate einfach in die neuen Projektschritte bzw. Sprints übernommen werden, ohne je gelöst zu werden, wobei sich die Probleme damit akkumulieren, bis das Projekt aus dem Ruder läuft. In einem Vertrag zu einem agilen Projekt müssen darum Zeitpunkt und Verbindlichkeit von Abnahmen bzw. Teil-Abnahmen vereinbart werden.

Aufgrund der speziellen Projekt-Eigenschaften besteht in agilen Projekten eine besondere Gefahr, dass auch die Kosten aus dem Ruder laufen. Ich staune zudem als Jurist, wie in Projekten hunderttausende, ja Millionen von Schweizerfranken ohne klare Bedingungen zwischen den Partnern fliessen. Aus juristischer Sicht muss jedoch absolut nachvollziehbar sein, für was ein Franken bezahlt wird. Andernfalls können insbesondere Preisminderungen und Schadenersatz nur sehr schwierig berechnet werden. Es muss auch ein eindeutiges Preismodell vereinbart werden, wie Pauschalpreis, Kostendach oder Verrechnung nach Aufwand. Zahlungen sollten mit eindeutigen Milestones verbunden werden.

Bei agilen Projekten tendieren nach meiner Beobachtung die Partner zum «Laissez-faire», mit regelmässig fatalen Folgen. Gerade in solchen Projekten braucht es aus juristischer Sicht ein striktes Controlling. Dazu eignet sich u.a. die Vereinbarung von Milestones; auch wenn diese allenfalls nur für Teilprojekte bzw. Sprints festgehalten werden. Wie erwähnt gehört dazu auch das Finanz- bzw. Zahlungsmanagement.

In vielen, notabene Langzeit-Projekten, insbesondere im Bereich IT, sitzen die Projektpartner nicht nur in demselben Boot, sondern in demselben U-Boot; und es ist für alle besser, wenn niemand eine Luke öffnet! Mit anderen Worten, ab einem gewissen Projektfortschritt ist bei Meinungsverschiedenheiten der Projektpartner ein Exit de facto für alle Beteiligten nicht mehr realistisch. Aus diesem Grund sind ein vorab vereinbartes juristisches Changemanagement und ein Eskalationsverfahren fundamental. Insbesondere muss ein Gang ans Gericht um jeden Preis vermieden werden. Diesbezüglich vereinbaren die Parteien, wie sie mit notwendigen Projektänderungen umgehen, die entweder von einem der Projektpartner verlangt oder aufgrund veränderter Umstände notwendig werden. Zudem einigen sich die Partner vorab auf ein Verfahren, mit dem sie Meinungsverschiedenheiten eskalieren können. Das Eskalationsverfahren besteht aus einem internen und einem externen Teil, wobei man davon ausgeht, dass eine Problemlösung wahrscheinlicher wird, je weiter weg sie von den unmittelbar Involvierten getroffen wird. Im internen Verfahren wird ein Problem direkt zwischen den Projektverantwortlichen der jeweiligen Projektpartner besprochen. Kommen diese zu keiner Einigung, wird das Problem nach oben an die Geschäftsleitungen der Projektpartner weitergereicht. Können sich auch diese nicht einigen, versuchen es bei einer Aktiengesellschaft als nächstes die Verwaltungsräte. Kommt es auch hier zu keiner Einigung, erfolgt der Schritt aus dem Projekt heraus zu einer Mediation und als letzter Schritt zu einem Schiedsrichter oder einem Schiedsgericht, die in der Sache entscheiden.

*www.linkedin.com/in/ueli-grueter, www.twitter.com/juristenfutter, www.digilaw.ch

Aktualisiert am 27. April 2020