In meiner über 20-jährigen Tätigkeit als Rechtsanwalt habe ich regelmässig Klienten und Gegenparteien versucht von einer gütlichen Einigung (jur. «Vergleich») zu überzeugen. Ab und zu ist das gelungen, häufiger beharrten die Parteien aber auf ihren Standpunkten und stürzten sich in mehrjährige gerichtliche Auseinandersetzungen. Vor kurzem habe ich sogar entnervt in einem über 6-jährigen (sic!), sinnlosen Rechtsstreit das Mandat niedergelegt. Nun hat es Katrin Sachse, stv. Chefradakteurin bei der BUNTE, in ihrer aktuellen Kolumne «Small Talk» auf den Punkt gebracht und stellt fest: In einem Familienstreit in einem Lebensmittelkonzern sind die einzigen Gewinner die Anwälte, die schon Millionen an Honorare kassiert haben; und Jura-Professoren, die damit einen neuen Musterfall für eine verpfuschte Unternehmensnachfolge erhalten. Exakt so ist es. Auch wenn ich (leider) in meinen Fällen keine Millionen an Honorare kassiere, sind gerade Gerichtsfälle lukrativ. Denn, wenn die Klienten einmal in der Gerichts-Pipeline drin sind, gibt es finanziell kein Entrinnen mehr. Zudem machen Fälle aus der eigenen Praxis meinen Unterricht an der Hochschule besonders lebendig. Und, natürlich spreche ich mit meinen Studierenden auch über alternative Methoden der Streitbeilegung (Alternative Dispute Resolution), die ich, gerade wegen diesen Erfahrungen, sehr empfehle! Die Details dazu finden Sie in meinem Online-Teaching-Tool digilaw.ch: Dispute Resolution und Rechtsdurchsetzung in der digitalen Welt.
Gerade brüte ich über hunderten von E-Mails zwischen meiner Klientin und ihrer Auftragnehmerin, einer Software-Entwicklerin. Ein sogenannt agiles Projekt ist aus dem Ruder gelaufen. Nun will meine Klientin Mängel geltend machen. Dafür wäre wichtig zu wissen, was die Parteien konkret vereinbart haben. Nicht ganz einfach bei einer rollenden Planung. Nichtsdestotrotz, auch agile Projekte müssen juristisch niet- und nagelfest sein.
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.
