• Facebook
  • Google+
  • Twitter
  • XING

Vertragsgestaltung bei Webprojekten: Klassisches oder agiles Projektmanagement?

© pressmaster - Fotolia.com

„Agilität" ist auf dem Vormarsch. Im Vergleich zu einem klassischen Projektmanagement werden agile Vorgehensweisen vor allem als kundengerechter, schneller und kostengünstiger gepriesen. Warum das klassische Projektmanagement weiterhin eine Daseinsberechtigung hat und welche rechtlichen und vertragsgestalterischen Stolpersteine agile Projektmethoden mit sich bringen, wird in dem folgenden Beitrag dargestellt. 

Wer plant, ein Webprojekt zu beauftragen oder seinen Online-Shop überarbeiten zu lassen, hat meist eine gewisse Vorstellung von dem zu erzielenden Ergebnis. Oft stehen dabei zwar Funktionalitäten im Vordergrund; auch Design, Ergonometrie sowie look-and-feel werden jedoch eine wesentliche Rolle spielen. Der Detailgrad der Vorstellung vor Vertragsschluss variiert freilich sehr stark und ist von der (häufig fehlenden) Expertise des Kunden abhängig. 

Probleme des klassischen „Wasserfalls“

Nach einer klassischen Vorgehensweise entsprechend dem Wasserfallmodell steht vor der eigentlichen Projektumsetzung durch den Entwickler zunächst die Projektplanung. Ergebnis dieser Planung ist in der Regel ein Feinkonzept (Pflichtenheft), in welchem das Projektziel vollständig umschrieben wird. Eventuell basiert dieses auf einem Lastenheft, in dem der Kunde seine Anforderungen an das Projektziel grob beschrieben hat. Das Pflichtenheft wird dabei in seltenen Fällen vom Kunden selbst, in den meisten Fällen jedoch gemeinsam von Kunde und Entwickler erstellt. Erst nach Abschluss dieser Planung, also mit Fertigstellung des Pflichtenheftes, beginnt die eigentliche Realisierung des Webprojektes. Die Realisierungsphase baut dabei auf dem Ergebnis der Planungsphase auf.

Dieses lineare Vorgehen birgt allerdings eine Reihe systemimmanenter Projektrisiken, die nicht selten Auslöser von Auseinandersetzungen, Verzögerungen oder sogar Projektabbrüchen sind. Dem Kunden ist es auf der vorgelagerten, abstrakten Ebene häufig nicht möglich, vor der Projektumsetzung die wichtigen von den unwichtigen oder überflüssigen Funktionen und Features zu unterscheiden. Aus Angst, in der Zukunft erforderliche oder nützliche Funktionen zu übersehen, ist das Pflichtenheft deshalb oft „überladen“. Das führt nicht nur zu einer Verlängerung des Projektzeitraums, sondern auch zu unnötig hohen Kosten für den Auftraggeber. Ein ganz wesentliches Problem der klassischen Projektmethode liegt zudem außerhalb der Kontrolle von Auftraggeber und Softwareentwickler: Es ist häufig nicht möglich, bereits bei der Projektplanung vorauszusehen, welche Funktionen oder Schnittstellen zum Zeitpunkt der Projektbeendigung tatsächlich erforderlich, aktuell und „state-of-the-art“ sind. Seit jeher werden deswegen vertraglich Prozesse zur Aktualisierung des Vertragsgegenstandes im Realisierungsprozess vereinbart (sog. Change Management). Damit soll das Projektziel entsprechend der aktuellen technologischen Entwicklung und den neuen Anforderungen des Kunden in der Umsetzungsphase angepasst werden. Der im klassischen Projektmanagement angelegte statische Prozess wird damit flexibler gestaltet.

In der Praxis gibt das Verfahren zur Änderung des Vertragsgegenstandes allerdings häufig Anlass zu Diskussionen über Machbarkeit, Umfang, Zeitverzögerung und zusätzliche Kosten. Gerade in einem stark volatilen technologischen Umfeld wie dem von Webprojekten birgt das Change Management deswegen ein nicht unerhebliches Streit- und Risikopotential. Der Grund dafür liegt im Change Management als Flexibilisierungsinstrument selbst. Denn im Rahmen einer klassischen Vorgehensweise stellt jede Flexibilisierung letztlich einen Fremdköper dar, der den idealtypisch linearen Projektverlauf stört und behindert. Für den Auftraggeber bedeutet die Flexibilisierung, die er durch die Möglichkeit von Change Requests erhält, zudem in der Regel vor allem zusätzliche ungeplante Kosten. 

Agile Projektmethoden als Heilsbringer?

An diesen Schwachstellen linearer Entwicklungsmethoden setzt agiles Projektmanagement an. Beispielhaft sei hier auf die weit verbreitete Scrum-Methode verwiesen: Statt eines linearen Prozesses, in welchem die Projektplanung abstrahiert vor der Realisierung stattfindet, werden Planungs- und Umsetzungsphasen gemeinsam in mehreren iterativen Schleifen wiederholt. Zu Projektbeginn existiert allenfalls eine „grobkörnig“ beschriebene Projektvision, die sich im Rahmen des Prozesses zu einem detaillierten Projektziel hin entwickelt. Im Vordergrund steht dabei die enge Zusammenarbeit von Entwickler und Auftraggeber; alle Entscheidungen sollen gemeinsam besprochen und gemeinsam gefällt werden. Auf Grundlage der Zwischenergebnisse der Entwicklung werden gemeinsam neue Ideen entwickelt und ohne „Denkverbote“ diskutiert. Die Flexibilität ist dabei institutionalisiert: Weiterentwicklungen und Änderungen des Vertragsgegenstandes sind beabsichtigt und Ausgangspunkt des Verständnisses beider Parteien. Agilität verspricht deswegen ein besonders bedarfsgerechtes und zeitgemäßes Projektergebnis.

Obschon deshalb agiles Projektmanagement dem klassischen Vorgehen überlegen zu sein scheint, ist absolute Agilität für viele Auftraggeber keine echte Option. Denn aufgrund der starken Einbeziehung des Auftraggebers über die gesamte Projektlaufzeit hinweg werden Personalressourcen gebunden. Im Rückblick mag sich dieser Aufwand zwar auszahlen, wenn das Ergebnis den Bedürfnissen des Auftraggebers in hohem Maße entspricht. Das ist jedoch zunächst ungewiss. Deswegen scheuen sich viele Auftraggeber, mit diesem Personalaufwand in Vorleistung zu treten. Häufig fehlt es auch schlicht an internen Ressourcen mit ausreichendem Projekt-Know-How.

Ein weiteres wesentliches Problem ist die mangelnde Kostentransparenz: Da nicht feststeht, was vom Auftragnehmer entwickelt werden soll, kann im vorneherein auch nicht feststehen, was die Entwicklung am Ende kostet. Häufig wird versucht, diesen Aspekt durch eine Festpreisvereinbarung zu entschärfen und Kostentransparenz zu schaffen („Agiler Festpreis“). Daraus folgt jedoch zwingend eine Einschränkung der gestalterischen Freiheit. Sollen neue Features umgesetzt werden, müssen im Gegenzug alte fallen gelassen werden. Andernfalls werden die zusätzlichen Kosten – entsprechend dem Change Management – gesondert berechnet.

Was bedeutet Agilität rechtlich?

Ungeachtet der Vor- und Nachteile beider Projektmethoden stellt sich aus vertragsgestalterischer Sicht eine ganz grundlegende Frage: Welchem Vertragstypus sind Softwareverträge zuzuordnen und unterscheiden sich agile Softwareverträge insoweit vom klassischen Softwarevertrag?

Die vertragstypologische Einordnung hat ganz entscheidenden Einfluss auf die Vertragsgestaltung. Denn das Bürgerliche Gesetzbuch sieht für eine Reihe von Vertragstypen bestimmte Regelungen vor, die Anwendung finden, wenn die Parteien nicht vertraglich etwas Abweichendes vereinbaren (z. B. in Bezug auf Gewährleistungsregeln oder Zahlungsmodalitäten). Nur wenn feststeht, um welchen Vertragstyp es sich handelt, können die Parteien (soweit das Gesetz dies zulässt) bewusst und individuell vom Gesetz abweichende Vereinbarungen treffen. Außerdem sind – und das ist insbesondere für Auftragnehmer von Bedeutung, die ein Vertragsmuster verwenden – die Maßstäbe einer Kontrolle der Vertragsklauseln auf Vereinbarkeit mit dem AGB-Recht je nach Vertragstyp unterschiedlich.

Gretchenfrage: Werk- oder Dienstvertrag?

Für die Vertragsgestaltung von klassischen und agilen Verträgen ist deswegen maßgeblich, welcher Vertragstyp des BGB jeweils Anwendung findet.

Für Verträge über Erstellung eines Online-Auftritts oder eines Web-Projekts kommt in erster Linie eine werkvertragliche oder dienstvertragliche Einordnung in Betracht. Werk- und Dienstvertrag unterscheiden sich wesentlich darin, dass der Auftragnehmer beim Werkvertrag einen konkreten Erfolg schuldet, beim Dienstvertrag dagegen lediglich zum Tätigwerden verpflichtet ist, ohne zugleich ein bestimmtes Ergebnis zu versprechen. Dementsprechend ist beim Werkvertrag allein der Auftragnehmer für den Projekterfolg verantwortlich und Weisungen des Auftraggebers – anders als beim Dienstvertrag – nicht unterworfen.

Die Unterscheidung ist vor allem deswegen relevant, weil das Werkvertragsrecht ein Mängelhaftungsrecht („Gewährleistung“) vorsieht, das Dienstvertragsrecht allerdings nicht. Vor allem der Auftragnehmer hat deswegen ein Interesse an dem Abschluss eines Dienstvertrages.

Entscheidend ist der Vertragsinhalt

Auf Softwareerstellungsverträge nach klassischer Vorgehensweise findet in aller Regel Werkvertragsrecht (bzw. unter bestimmten Umständen Werkliefer- und damit weitgehend Kaufrecht) Anwendung. Der Auftragnehmer schuldet dabei eine dem Pflichtenheft entsprechende Software und muss Abweichungen hiervon im Rahmen der Sachmangelhaftung („Gewährleistung“) beseitigen.

Im technischen Umfeld wird für Verträge auf Grundlage eines agilen Projektmanagements häufig davon ausgegangen, agile Projektentwicklung führe zu einer dienstvertraglichen Einordnung des Vertrages, da kein Pflichtenheft vorliegt und die Parteien gemeinschaftlich auf den Projekterfolg hinarbeiteten, sodass nicht nur der Auftragnehmer die Verantwortung für den Projekterfolg trage. Die Entscheidung agil oder klassisch hätte damit auch wesentliche juristische Bedeutung: Agil wäre grundsätzlich günstiger für den Auftragnehmer.

Eine pauschale Differenzierung „klassisch = Werkvertrag“, „agil = Dienstvertrag“ ist allerdings falsch und irreführend. Richtig ist lediglich, dass die juristische Klassifizierung eines Softwareerstellungsvertrages auf agiler Basis Schwierigkeiten bereiten kann und im Einzelfall möglicherweise vom klassischen Modell abweicht. Für die vertragliche Einordnung eines Vertrages entscheidend sind allerdings nicht die Überschrift oder Schlagwörter, die den Vertragsinhalt beschreiben. Maßgeblich sind allein die tatsächlich vereinbarten Vertragspflichten, in erster Linie diejenigen des Auftragnehmers.

Ein Softwareerstellungsvertrag auf agiler Basis kann also durchaus auch Werkvertrag sein. Schließlich erwartet der Auftraggeber in der Regel ein für ihn nutzbares Ergebnis als Vertragserfolg. Außerdem legen die Parteien auch bei agiler Vorgehensweise häufig ein – wenn auch vages – Projektziel fest (z. B. „Erstellung eines Web-Auftritts“), das den Rahmen der Entwicklung vorgibt. Verpflichtet sich der Auftragnehmer, die Verantwortung für das Erreichen dieses Projektziels zu übernehmen, ist grundsätzlich von einem Werkvertrag auszugehen. Um also tatsächlich zur Anwendung des Dienstvertragsrechts zu gelangen, müsste ausdrücklich vereinbart werden, dass der Auftragnehmer keinen Erfolg schuldet, sondern umgekehrt der Auftraggeber die Verantwortung für den Projekterfolg trägt. Der Auftraggeber „kauft“ bei dieser Gestaltung also letztlich Programmierzeit des Auftragnehmers, ohne eine konkrete Zusage für das Ergebnis zu bekommen.

Aus mehreren Gründen ist eine solche Vertragsgestaltung allerdings problematisch: Der Auftraggeber ist nur in den seltensten Fällen bereit, das alleinige Risiko für den Projekterfolg zu übernehmen. Es ist auch nicht recht plausibel, dass der Auftraggeber als technischer Laie die Verantwortung behält und der Auftragnehmer als Experte keine Erfolgsverantwortung übernimmt. Schließlich passt diese Konstruktion nicht zu dem Umstand, dass in der Regel der Auftragnehmer das Projekt steuert, wenn auch mit Unterstützung des Auftraggebers. Den Softwareerstellungsvertrag als reinen Dienstvertrag zu gestalten, ist also zwar rechtlich möglich, allerdings in der Praxis wohl kaum gegenüber dem Auftraggeber durchsetzbar und in den meisten Fällen nicht interessengerecht.

Bedarfsgerechte Vertragsgestaltung

Ziel der Vertragsgestaltung muss es deswegen sein, einen gleichermaßen bedürfnis- wie interessengerechten Zwischenweg zu finden. Insbesondere bei Scrum können etwa die Planung der Sprints („Sprint-Plannings“) und das „Sprint-Review“ sowie Scrum-Meetings auf Ebene eines Dienstvertrages geregelt werden. Für die einzelnen Sprints kann davon abweichend eine werkvertragliche oder werkliefervertragliche Gestaltung gewählt werden. Geschuldet ist dann jeweils ein Ergebnis mit der Funktionalität wie im Sprint-Backlog beschrieben.

Die so erzielte Aufspaltung in viele kleinere Werkverträge vermindert das Risiko auf beiden Seiten. Flexibilität wird dadurch sichergestellt, dass beide Parteien nach jedem oder einer bestimmten Zahl von Sprints den Vertrag kündigen können. Dabei kann entweder anhand des voraussichtlichen Aufwands die Vergütung eines einzelnen Sprints jeweils separat vereinbart, oder vertraglich ein fester Preis pro Sprint festgelegt werden.

Dies führt zwar möglicherweise ideologisch zu einer Vermengung von agiler und klassischer Entwicklungsweise. Zum einen scheint eine Zwischenlösung jedoch aus Interessengesichtspunkten sachgerecht und zum anderen ermöglicht sie auch konservativen Auftraggebern, die Vorteile agiler Entwicklungsmethoden nutzen zu können, ohne vollständig auf die gewohnte „Projektumgebung“ verzichten zu müssen.

Letztlich ist für die Vertragsgestaltung also nicht die Projektmethode maßgeblich. Entscheidend ist die Ausgestaltung der Zusammenarbeit für das konkrete Projekt. Erst auf dieser Basis kann ein sachgerechter Vertrag überhaupt entworfen werden. Inwieweit Werk- und Dienstvertrag diese Gestaltung beeinflussen, ist allein abhängig von dem Parteiwillen und nicht nur an die Frage der Projektmethode geknüpft.

Zusammenfassung

Agil oder klassisch? Aus vertragsgestalterischer Sicht ist die Frage nur von untergeordneter Bedeutung. Entscheidend ist letztlich, dass der Vertrag das von den Parteien beabsichtigte Vorgehen abbildet und alle wesentlichen rechtlichen Punkte, die damit in Zusammenhang stehen, regelt. Das setzt voraus, dass sich die Parteien über die grundlegenden Aspekte der Vorgehensweise bei der Projektumsetzung und über die Verteilung der Verantwortlichkeiten für den Projekterfolg einig sind. Dazu genügt es nicht, sich auf ein „agiles Vorgehen“ zu einigen. Denn das sagt noch nichts Konkretes über die Leistungspflichten aus und lässt eine Einordnung des Vertrages und eine sachgerechte Vertragsgestaltung nicht zu.

Ebenso wenig wie deswegen aus „agil“ zwingend die Anwendung des Dienstvertragsrechts folgt, sollten sich die Parteien ausschließlich von vertragstypologischen Erwägungen leiten lassen. Entscheidend ist eine rechtlich ausgewogene Lösung auf Grundlage der parteilichen Zusammenarbeit. Da diese von Fall zu Fall divergiert bedarf häufig auch der Vertrag einer bedarfsgerechten Gestaltung – ganz im Sinne des agilen Projektmanagements.

Autoren

Dr. Matthias Orthwein, LL.M. (Boston)
Dr. Matthias Orthwein ist Rechtsanwalt in München, Experte für IT Recht und E-Commerce und Partner bei der Wirtschaftskanzlei SKW Schwarz. Er berät seit vielen Jahren nationale und internationale Mandanten im IT-Recht, insbesondere im Softwarerecht und der rechtlichen Gestaltung des E-Commerce. Er ist zudem ein erfahrener Experte für nationale und internationale Datenschutzrechtsfragen. Dr. Orthwein ist Lehrbeauftragter für IT und Datenschutzrecht an der Hochschule Rosenheim.

www.skwschwarz.de

m.orthwein@skwschwarz.de

www.twitter.de/M_Orthwein

Daniel Meßmer
Daniel Meßmer ist Associate bei SKW Schwarz Rechtsanwälte und berät auf dem Bereich des IT-Rechts. Die Schwerpunkte seiner Arbeit liegen dabei insbesondere auf der bedürfnisgerechten Gestaltung und Strukturierung von Softwareverträgen (einschließlich der Beratung bei der Verwendung von Open-Source-Software) und der rechtlichen Unterstützung bei der Umsetzung von innovativen IT-Vorhaben.

www.skwschwarz.de

d.messmer@skwschwarz.de

Kommentare (0)

Keine Kommentare gefunden!

Neuen Kommentar schreiben

  • Facebook
  • Google+
  • Twitter
  • XING
© 2016 eSTRATEGY-Magazin
Facebook
Twitter
RSS
Xing
Google+