Wie an anderer Stelle ausführlich beschrieben, bezeichne ich unter dem Terminus der Projektverträge solche Verträge, die abgeschlossen werden mit dem Ziel, ein bestimmtes Produkt zu erstellen, wobei zum Zeitpunkt des Vertragsabschlusses die Planung darüber, was dieses Ziel sein soll, nicht im Detail abgeschlossen ist. Das Scheitern von Projektverträgen bedeutet für den Kunden, dass ein geplantes Ziel nicht zum beabsichtigten Zeitpunkt erreicht wird. Es bedeutet natürlich auch, viel Zeit und Geld verschwendet zu haben. Aus der Perspektive des IT-Unternehmens bedeutet ein gescheitertes Projekt das Risiko hoher finanzieller Belastung und der Verlust von Renommee am Markt.
Projekte zeichnen sich dadurch aus, dass festgelegt wird, wer was wann mit welchen Mitteln zu tun hat.
Der Ausgangspunkt: Keines der vom Gesetz vorgesehenen Modelle taugt wirklich.
Das Gesetz macht es sich im Werkvertragsrecht relativ leicht und spricht davon, dass die Sache frei von Sachmängeln ist, wenn sie die vertraglich vereinbarte Beschaffenheit aufweist. Es gibt im Projektgeschäft für die Erstellung von Software viele Namen, mit denen die Dokumente gekennzeichnet werden, aus denen sich der vertraglich vereinbarte Zustand der Software ergehen soll. Lastenheft, Pflichtenheft, Sprintblock, Back Log, etc. – all dies sind Namen für Dokumente, aus denen sich ergibt, welche Funktionen und Eigenschaften die Software in welcher Systemumgebung aufweisen soll. Natürlich gibt es zwischen diesen einzelnen Dokumenten Unterschiede und ich verkenne auch nicht, dass es bestimmte technische Anforderungen, wie ITL oder die DIN gibt, die sich darüber auslassen, welchen Inhalt die einzelnen Dokumente aufweisen sollten. Nur aus der juristischen Sicht ergibt sich zunächst einmal nur, dass die Parteien im Projektgeschäft einen Vertrag abschließen, in dem sie vereinbaren, dass etwas erstellt werden soll und dass diese vertraglich vereinbarte Beschaffenheit der Sache zum Zeitpunkt des Vertragsabschlusses eben noch nicht vollständig besteht. Das Projektgeschäft zeichnet sich typischer Weise dadurch aus, dass die Parteien etwas erstellen wollen und noch keine endgültig detaillierte Vorstellung über den Endzustand des Produktes haben. Trotzdem soll mit der Arbeit begonnen werden. Das Schöne ist, dass das Gesetz diese Verträge eigentlich nicht kennt. Projektverträge stellen eine Mischform zwischen Werkverträgen, Dienstverträgen und gesellschaftsrechtlichen Konstrukten dar.
Das Werkvertragsrecht passt eben nicht genau, weil es voraussetzt, dass die Planung zum Zeitpunkt des Vertragsabschlusses bereits abgeschlossen ist. Sofern ich einen Tischler damit beauftrage, einen Tisch zu erbauen, ist die Planung für diesen Tisch zum Zeitpunkt der Beauftragung bereits abgeschlossen. Der Tischler erfüllt den klar aus der Planung ersichtlichen Wunsch des Kunden/oder er tut es eben nicht. Der Tischler haftet für den Erfolg; er arbeitet eigenständig und ohne Einflussnahme des Kunden eigenverantwortlich und er haftet dafür, dass ein bestimmter Erfolg eintritt und wird nur unter der Voraussetzung bezahlt, dass dieser Erfolg tatsächlich eingetreten ist.
Mit dem Projektgeschäft hat diese Arche typische Form, die das Gesetz vorsieht, nichts zu tun. Weder ist die Planung zum Zeitpunkt des Vertragsabschlusses vollständig abgeschlossen, noch arbeitet das IT-Unternehmen vollständig eigenständig. Es soll aber nach dem Wunsch des Auftraggebers trotzdem auf der Grundlage des Werkvertragsrechts haften, wenn ein bestimmter Erfolg nicht eintritt. Das Tückische am Werkvertragsrecht besteht nun darin, dass das Gesetz sagt, dass die Sache nicht nur dann frei von Mängeln ist, wenn sie die vereinbarte Beschaffenheit aufweist. Neben der vertraglich vereinbarten Beschaffenheit stellt das Gesetz darauf ab, dass die erstellte Sache geeignet ist, den vom Auftraggeber vorausgesetzten Zweck zu erfüllen. Mit dieser Formulierung will das Gesetz diejenigen Fälle erfassen, in denen die Spezifikation nicht vollständig oder fehlerhaft ist und besagt inhaltlich, dass der Auftragnehmer im Falle des Fehlens einer Spezifikation ein Werk mittlerer Art und Güte zu erschaffen hat. Trocken gesagt: Auch dann, wenn in der Spezifikation für die Erstellung eines Hauses nicht ausdrücklich vermerkt ist, dass das Haus Heizung und eine Toilette aufweist, kann der Auftraggeber davon ausgehen, dass das zu erstellende Haus eine Heizung und eine Toilette aufweist. Anderenfalls ist es mangelhaft.
Das Dienstvertragsrecht wäre aus der Sichtweise des ITlers ideal. Hier wird das IT-Unternehmen nur dafür bezahlt, dass es sich bemüht, einen bestimmten Erfolg zu erreichen, ohne dass eine Erfolgshaftung besteht. Das IT-Unternehmen hat mit der Sorgfalt eines Fachmannes vorzugehen, haftet aber eben nicht dafür, dass das abzuliefernde Resultat den Vorgaben des Kunden entspricht und kann auch nicht mit Ansprüchen auf Rückgewähr, Minderung etc. bedroht werden. Es ist zwar nicht zu unterschätzen, dass die Möglichkeit Schadensersatz zu fordern, nach der Schuldrechtmodernisierungsreform im Jahre 2002 das Dienstvertragsrecht zu einer deutlich schärferen Waffe hat werden lassen. Auch im Dienstvertragsrecht kann der Geschädigte Kunde Schadensersatz und Schadensersatz anstelle der Leistung gemäß den §§ 281, 284 BGB fordern. Aber insgesamt ist das Dienstvertragsrecht für den Auftragnehmer sicher sehr viel komfortabler. Aus der Sichtweise des Kunden taugt das Dienstvertragsrecht nur dann, wenn man dem Auftragnehmer wirklich traut. Denn eine Erfolgskontrolle lässt das Dienstvertragsrecht nicht zu. Der Kunde zahlt für die Bemühung ein bestimmtes Werk zu erreichen, kann aber keine Ansprüche aus dem Nichterreichen eines bestimmten Erfolges ableiten. Für das Projektgeschäft taugt das Dienstvertragsrecht im Grunde genommen sehr, da es nicht voraussetzt, dass zum Zeitpunkt des Abschlusses des Vertrags alle Einzelheiten über das zu erreichende Ziel schon vollständig durchgeplant sind. Es ist genauso, wie im Angestelltenverhältnis: Sofern man einen Programmierer einstellt, muss zum Zeitpunkt der Anstellung nicht gesamte Lastenheft und Softwaredesign fertiggestellt sein.
Gesellschaftsrechtliche Verknüpfungen sind aus der Sichtweise des Auftraggebers aus den gleichen Gründen abzulehnen, die auch schon gegen die Anwendbarkeit des Dienstvertragsrechts sprachen. Für die Anwendbarkeit gesellschaftsrechtlicher Strukturen auf das Projektgeschäft spricht stets, dass wie im Gesellschaftsrecht Projekte nur dann ein Erfolg werden können, wenn beide Parteien viel miteinander kommunizieren und einzelne, zeitlich eng gefasste Kontrollen, Koordination und Absprachen stattfinden. Aber erneut wird man konstatieren müssen, dass das Gesellschaftsrecht deswegen keine adäquate Grundlage für die Regelung für das Projektgeschäft darstellt, weil es keine Erfolgsbezogenheit beinhaltet.
Risiken aus dem Projektgeschäft können nur durch vertragliche Regelungen aufgefangen und verbessert werden. Wie das funktioniert, lesen Sie in den nächsten Blogs.
