{"id":1471,"date":"2020-02-12T14:21:58","date_gmt":"2020-02-12T13:21:58","guid":{"rendered":"https:\/\/hub.hslu.ch\/management-and-law\/?p=1471"},"modified":"2026-02-11T14:53:46","modified_gmt":"2026-02-11T13:53:46","slug":"wenn-agile-projekte-aus-dem-ruder-laufen-legal-lessons-learned","status":"publish","type":"post","link":"https:\/\/hub.hslu.ch\/management-and-law\/2020\/02\/12\/wenn-agile-projekte-aus-dem-ruder-laufen-legal-lessons-learned\/","title":{"rendered":"Wenn agile Projekte aus dem Ruder laufen – legal lessons learned"},"content":{"rendered":"\n\n\n

Rollende Planung f\u00fcr flexible Produktentwicklung<\/strong><\/h4>\n\n\n\n

Auch wenn sich die Verantwortlichen der Sache oft nicht bewusst sind, werden immer mehr digitale Projekte \u00abagil\u00bb organisiert, wobei die \u00dcberg\u00e4nge von \u00abfix\u00bb zu \u00abagil\u00bb 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 \u00abSprints\u00bb 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\u00e4nkt, sondern kommen auch in anderen Bereichen zur Anwendung, wie z.B. in der Architektur. So hatte das Schweizer Architekturb\u00fcro Herzog & de Meuron zwar eine Vorstellung davon, wie einst das Konzerthaus \u00abElbphilharmonie\u00bb 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\u00f6gerungen auch mehrmals aus dem Ruder zu laufen drohte und vor Gericht landete. Genau dies gilt es aber unbedingt zu verhindern.<\/p>\n\n\n\n

Juristische Problemfelder bei agilen Projekten<\/strong><\/h4>\n\n\n\n

Auch wenn es Juristinnen und Juristen lieber w\u00e4re, ihre Unternehmen und Klienten w\u00fcrden ihre Projekte fix und nicht agil planen, m\u00fcssen sie sich als Dienstleister den Umst\u00e4nden anpassen. Daf\u00fcr ist es wichtig die Problemfelder agiler Projekte zu kennen.<\/p>\n\n\n\n

In der Praxis habe ich festgestellt, dass sich die Projektpartner oft der agilen Projekte nicht bzw. nicht wirklich bewusst<\/em> sind. Damit ist ihnen regelm\u00e4ssig auch die praktische, schon gar nicht die juristische Problematik klar.<\/p>\n\n\n\n

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

In einem fixen Projekt wird in der Regel ein Auftrag erteilt, wobei der Auftragnehmer diesen eigenst\u00e4ndig ausf\u00fchrt und abliefert. In agilen Projekten dagegen arbeiten Auftragnehmer und Auftraggeber, soweit man diese als solche \u00fcberhaupt noch abgrenzen kann, eng zusammen und damit \u00fcberschneiden und verwischen sich oft die Verantwortlichkeiten<\/em>.<\/p>\n\n\n\n

Die enge personelle Kooperation kann dar\u00fcber hinaus auch zu unklaren arbeitsrechtlichen Verh\u00e4ltnissen f\u00fchren, insbesondere zum Personalverleih<\/em>, der unter bestimmten Bedingungen sogar bewilligungspflichtig ist; mit Straffolgen bei Missachtung.<\/p>\n\n\n\n

Rollend<\/em> geplant werden nicht nur die agilen Projekte an sich, sondern auch deren Finanzierung<\/em>. Sp\u00e4testens wenn diese aus dem Ruder l\u00e4uft, 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\u00f6ffnung der Elbphilharmonie im Jahre 2017 sind die Koste auf rund 860 Millionen Euro angestiegen (sic!).<\/p>\n\n\n\n

Hotspots eines Vertrages f\u00fcr agile Projekte<\/strong><\/h4>\n\n\n\n

Auch wenn die Anlage bei agilen Projekten aus juristischer Sicht schwierig ist, lassen sich aus den genannten Problemfeldern Hotspots f\u00fcr die Vertragsgestaltung ableiten, mit denen juristische Auseinandersetzung wenn nicht verhindert, dann doch vermindert und in geordneten Bahnen bew\u00e4ltigt werden k\u00f6nnen.<\/p>\n\n\n\n

Gleich zu Beginn des Vertrages sollten sich die Partner die Projektmethode<\/em> bestimmen.<\/p>\n\n\n\n

Auch wenn es zur DNA eines agilen Vertrages geh\u00f6rt, dass die Projektziele laufend entwickelt und erg\u00e4nzt werden, sollte versucht werden im Vertrag ein mindestens \u00fcbergeordnetes<\/em>, wenn auch wenig konkretes Projektziel<\/em> zu beschreiben.<\/p>\n\n\n\n

Es folgt die die Definition der Projektorganisation<\/em> und der Projektf\u00fchrung<\/em>. Dabei geht es u.a. auch um die Frage, wer welche Rolle im Projekt \u00fcbernimmt; bei der Projektmethode \u00abScrum\u00bb z.B. wer Product Owner ist, wer zum Entwicklungsteam geh\u00f6rt und wer die Rolle des Scrum Masters \u00fcbernimmt.<\/p>\n\n\n\n

Da eine enge Zusammenarbeit<\/em> und Kommunikation<\/em> 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\u00f6rt auch die Mitwirkungspflicht des Auftraggebers, falls ein solcher in dieser herk\u00f6mmlichen Art effektiv existiert.<\/p>\n\n\n\n

In agilen Projekten beobachte ich ein \u00abManagement by E-Mail\u00bb. Es fehlen klare, \u00fcbersichtliche Protokolle<\/em> und Reports<\/em>, 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\u00fcr Dokumentationen<\/em>. Solch oberfl\u00e4chliches Handeln macht es sp\u00e4ter insbesondere f\u00fcr Dritte schwierig bis unm\u00f6glich, Projektschritte, Projekt\u00e4nderungen und Projektresultate nachzuvollziehen und zu verstehen.<\/p>\n\n\n\n

In den Vereinbarungen betreffend Projektorganisation, Projektf\u00fchrung, Zusammenarbeit und Kommunikation muss eine klare Abgrenzung der Verantwortlichkeiten<\/em> enthalten sein, die es sp\u00e4ter erm\u00f6glicht, zu eruieren, wer f\u00fcr M\u00e4ngel und allf\u00e4llige Sch\u00e4den haftet.<\/p>\n\n\n\n

Auch bei einer flexiblen und schnellen Projektentwicklung d\u00fcrfen Abnahmen<\/em> nicht fehlen. Immer wieder kann man beobachten, dass mangelhafte Projekt-Teilresultate einfach in die neuen Projektschritte bzw. Sprints \u00fcbernommen werden, ohne je gel\u00f6st zu werden, wobei sich die Probleme damit akkumulieren, bis das Projekt aus dem Ruder l\u00e4uft. In einem Vertrag zu einem agilen Projekt m\u00fcssen darum Zeitpunkt und Verbindlichkeit von Abnahmen bzw. Teil-Abnahmen vereinbart werden.<\/p>\n\n\n\n

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\u00fcr was ein Franken bezahlt wird. Andernfalls k\u00f6nnen insbesondere Preisminderungen und Schadenersatz nur sehr schwierig berechnet werden. Es muss auch ein eindeutiges Preis<\/em>modell vereinbart werden, wie Pauschalpreis, Kostendach oder Verrechnung nach Aufwand. Zahlungen sollten mit eindeutigen Milestones verbunden werden.<\/p>\n\n\n\n

Bei agilen Projekten tendieren nach meiner Beobachtung die Partner zum \u00abLaissez-faire\u00bb, mit regelm\u00e4ssig fatalen Folgen. Gerade in solchen Projekten braucht es aus juristischer Sicht ein striktes Controlling<\/em>. Dazu eignet sich u.a. die Vereinbarung von Milestones; auch wenn diese allenfalls nur f\u00fcr Teilprojekte bzw. Sprints festgehalten werden. Wie erw\u00e4hnt geh\u00f6rt dazu auch das Finanz- bzw. Zahlungsmanagement.<\/p>\n\n\n\n

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\u00fcr alle besser, wenn niemand eine Luke \u00f6ffnet! Mit anderen Worten, ab einem gewissen Projektfortschritt ist bei Meinungsverschiedenheiten der Projektpartner ein Exit de facto f\u00fcr alle Beteiligten nicht mehr realistisch. Aus diesem Grund sind ein vorab vereinbartes juristisches Changemanagement<\/em> und ein Eskalationsverfahren<\/em> fundamental. Insbesondere muss ein Gang ans Gericht um jeden Preis vermieden werden. Diesbez\u00fcglich vereinbaren die Parteien, wie sie mit notwendigen Projekt\u00e4nderungen umgehen, die entweder von einem der Projektpartner verlangt oder aufgrund ver\u00e4nderter Umst\u00e4nde notwendig werden. Zudem einigen sich die Partner vorab auf ein Verfahren, mit dem sie Meinungsverschiedenheiten eskalieren k\u00f6nnen. Das Eskalationsverfahren besteht aus einem internen und einem externen Teil, wobei man davon ausgeht, dass eine Probleml\u00f6sung 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\u00e4ftsleitungen der Projektpartner weitergereicht. K\u00f6nnen sich auch diese nicht einigen, versuchen es bei einer Aktiengesellschaft als n\u00e4chstes die Verwaltungsr\u00e4te. 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.<\/p>\n\n\n\n

Weitere Informationen und spannende Beitr\u00e4ge zu rechtlichen Hotspots bei agilen und digitalen Projekten finden Sie hier:<\/p>\n\n\n\n