Der IT Systemvertrag, Teil 6: Die IT-Projektorganisation

Haben Auftraggeber und Auftragnehmer den Vertrag erfolgreich vertragstypologisch "sauber" gestaltet, dann wird oft in der Projektorganisation ein systematischer Fehler begangen. Hat der Auftraggeber also den Vertrag als Werkvertrag gestaltet und zum Ausdruck gebracht, dass der Auftragnehmer allein die Projekt- und Erfolgsverantwortung hat, dann muss er die Projektverantwortung in der Projektorganisation auch dem Auftragnehmer überlassen. Dies geschieht aber oft nicht. Der Vertrag wandelt sich dann möglicherweise in einen Dienstvertrag oder in ein Kooperationsmodellum.

1. Allgemeines

Haben Auftraggeber und Auftragnehmer den Vertrag erfolgreich vertragstypologisch „sauber“ gestaltet, dann wird oft in der Projektorganisation ein systematischer Fehler begangen. Hat der Auftraggeber also den Vertrag als Werkvertrag gestaltet und zum Ausdruck gebracht, dass der Auftragnehmer allein die Projekt- und Erfolgsverantwortung hat, dann muss er die Projektverantwortung in der Projektorganisation auch dem Auftragnehmer überlassen. Dies geschieht aber oft nicht. Der Vertrag wandelt sich dann möglicherweise in einen Dienstvertrag oder in einen Kooperationsvertrag um.

2. Projektorganisationsformen, Vertrags- und - Projektgestaltung

In Verbindung mit der rechtlichen Einordnung kann man in der Praxis zwischen folgenden Typen von Projekt-Organisations-Formen unterscheiden, deren Vorliegen. auch für die Beantwortung der Frage wesentlich ist, welche Pflichten die Parteien haben und wer für Vertragstörungen zu haften hat.

2.1 Erfolgsrisiko beim Auftragnehmer (Werkvertrag)

In einem klassischen Auftraggeber-/Auftragnehmer-Verhältnis, das als Werkvertrag ausgestaltet ist, liegt das Erfolgsrisiko weitgehend beim Auftragnehmer ( §§ 631 ff. BGB) . Entsprechend hat der Auftraggeber Mitwirkungspflichten, der Auftragnehmer die Projektverantwortung. Hier wird es darauf ankommen, dass der Auftragnehmer dem Auftraggeber, wenn dieser erkennbar Laie ist, die Notwendigkeit der Zusammenarbeit, und die Notwendigkeit der Übermittlung von Leistungsvorgaben (z.B. "Pflichtenhefts") deutlich zur Pflicht macht. Möglicherweise hat der Auftragnehmer auch als Folge seine Projektverantwortung,den Auftraggeber während des Projekts bei der Ermittlung der Projektvorgaben zu unterstützen, zumindest dazu Hilfe anzubieten und den Auftraggeber auf die Nichteinhaltung seiner Mitwirkungsleistungen hinzuweisen. Diese Informationspflichten finden sich in komplexen Langzeitprojekten immer dort, wo schutzwürdiges Informationsbedürfnis des einen Vertragspartners auf einen Informationsvorsprung des anderen trifft und zwischen beiden eine besondere Vertrauensprägung gegeben ist. Die Beherrschung komplexer Langzeitvertragsverhältnisse erfordert die ständige Kommunikation zwischen den Beteiligten und den ständigen Abgleich mit der Wirklichkeit. Dem dienen unter anderem vertraglich normierte Informations- und Hinweispflichten. vor allem wenn der Auftraggeber auf Anforderung der Vorgaben nicht reagiert.

2.2 Projektverantwortung beim Auftraggeber (Dienstvertrag, 611 ff. BGB)

Ist der IT-Systemvertrag vertragstypologisch als Dienstvertrag gestaltet, erteilt der Auftraggeber dem Auftragnehmer detaillierte fachliche Weisungen (nicht verhaltens- oder personenbedingte). Ein Erfolg des Projektes ist in diesem Fallnoch nicht absehbar und ist auch nicht geschuldet. Der Auftragnehmer "unterstützt" den Auftraggeber leldiglich bei der Projekttätigkeit. Die Projektverantwortung beim Dienstvertrag liegt, wenn sie nicht gesondert dem Auftragnehmer, etwa als Projektleiter übertragen wird, beim Auftraggeber. Die Anforderungen an die Aufklärung und Beratung dürften erheblich abgesenkt sein.

2.3 Auftraggeber tragen gemeinsam die Projektverantwortung (Kooperationsmodell)

Es ist eine weit verbreitete und in Notsituationen gern geäußerte Vorstellung, bei Software-Projekten, insbesondere beim Auftrag zur Erstellung von Software bzw. bei System-Verträgen, würden Auftragnehmer und Auftraggeber "in einem Boot sitzen" mit der Folge, dass man sich bei Störungen (wieder) zusammensetzt, um gemeinsam nach Lösungen zu suchen. Der Erfolg, den eine der beiden Parteien bewirken soll, ist nicht erkennbar. Es ist unklar, was hier gelten soll. Eine Gesellschaft ist wohl nicht gewollt. Es wird schwer, die Projektverantwortung auszumachen. Evtl. tragen beide Partner diese. Die Verantwortungsbereiche und deren Verletzung sind schwer zu entflechten. Dementsprechend ist auch die eindeutige Zuordnung der Aufklärungs- und Beratungspflicht schwierig.

3. Forschungs- und Entwicklungsprojekte

Bei so genannten F&E-Projekten kann es sich um einen Dienst- oder Werkvertrag oder handeln. Es kommt darauf an, ob eine Dienstleistung, o als solche oder o als Arbeitsergebnis deren Erfolg geschuldet ist.

4. Das Kooperationsmodell und seien Risiken

4.1 Inhalt des Kooperationsmodells

Haben die Parteien ihrer Projektverantwortung nicht ausreichend und detailliert vertraglich festgelegt, besteht das Risiko das im Konfliktfall die Gerichte den Parteien eine „Pflicht zur Kooperation“ auferlegen. Diese Pflicht ist ein Ausdruck der in diesen oftmals komplexen Langzeitvertragsverhältnissen geltenden erhöhten Treuepflicht, die ihrerseits in § 242 BGB ihre Grundlage findet, wenn keine andersartigen vertraglichen Regelungen getroffen sind.

Diese Pflicht hat eine entscheidende Konsequenz: Durch die Einführung des § 241 II BGB i.R. des Schuldrechtsmodernisierungsgesetzes hat der Gesetzgeber die bislang aus § 242 BGB abgeleiteten Schutzpflichten (dem Erhaltungsinteresse dienend) deutlich von den weiterhin unter § 242 BGB zu fassenden Treuepflichten (dem Leistungsinteresse dienend) abgegrenzt. Nur erstere gelten gem. § 311 II BGB im bislang durch die culpa in contrahendo geschützten vorvertraglichen Bereich. Die vom BGH in seiner Kooperationsentscheidung aus dem Jahr 1999 (BGHZ 143, 89 = NJW 2000, 807 = BauR 2000, 409) betonte allgemeine Pflicht der Bauvertragsparteien zur Kooperation konkretisiert sich in besonderen Kooperationspflichten, namentlich Informations-, Verhandlungs- und Mitwirkungspflichten. Diese im Einzelnen darzustellen, würde den Rahmen dieses Beitrags sprengen. Die Kooperationspflichten dürfen aber nicht zur Allzweckwaffe der Gerichte werden, um gesetzlich oder vertraglich getroffene Risikozuweisungen zu umgehen, so der BGH in seinem „Schürmannbau-Beschluss“ aus dem Jahr 2003 (BGH, Beschl. v. 5. 6. 2003 - VII ZR 186/01, NZBau 2003, 433 = IBR 2003, 467 m. Anm. Quack), in dem er dem von ihm selbst verursachten „Ausverkauf der Kooperationspflichten“ in seiner Kooperationsentscheidung aus dem Jahr 199 wieder einen Riegel vorschob.

4.2 Risiken des Kooperationsmodells

4.2.1 Vermischung von Dienst- und Werkvertrag

Das BGB stellt für die beiden Vertragstypen Dienst- und Werkvertrag zwei verschiedene "Organisationsmodelle" zur Verfügung. Eine Vermischung dieser beiden Verträge führt, falls es zu einer gerichtlichen Überprüfung des Vertrages kommt, zu erheblichen Problemen. Diese zeigen sich etwa exemplarisch in der Unsicherheit, wie die Kombination von Überlassung von Standardsoftware mit Installation und anderen Leistungen unterschiedlich beurteilt wird. Es lohnt sich deshalb - je nach Interessenlage bereits bei der Vertragsgestaltung die grundsätzliche Entscheidung zu treffen und bei der Gestaltung zu manifestieren,

• ob der Vertrag mehr dem Dienst-
• oder mehr dem Werkvertrag angenähert sein soll bzw.
• ob er insgesamt sich an einem der beiden Vertragstypen orientiert.

Im Extremfall könnte man auf die Idee verfallen (bei Gericht nicht abwegig), es liege eine Gesellschaft vor, die erhebliche Besonderheiten insbesondere hinsichtlich einer evtl. Rückabwicklung (Auflösung) aufweist. Auch kommt in Betracht, dass beim Projekt einzelne Teile, vor allem Hardware und Standardsoftware "verkauft" werden. Insofern kann das Projekt aus einer Kombination von einzelnen Vertragsgegenständen bestehen.

4.2.2 Abhängigkeit der Leistungen, Konsequenzen bei Scheitern der Kooperation

Einer der wesentlichen Gründe, die die oben erwähnte Komplexität der EDV-Projekte ausmachen, ist die Abhängigkeit der Leistungen von einander, so etwa Art und Umfang der Hardware, die Auswahl des Datenbanksystems, die Auswahl der Module beim Standard - Anwendungsprogramm und deren Anpassung, die Altdatenübernahme und die Einweisung sowie die an die Abnahme bzw. Inbetriebnahme anschließende Pflege. Auch solche Auftragnehmer, die die Kooperation in ihren Anpreisungen besonders herausstellen, wollen diese Abhängigkeit der Leistungen meiden und nur die Standardsoftware als solche "verkaufen" und im übrigen evtl. selbst oder über Dritte nach Weisung des Auftraggebers noch gewisse Einstellungen/Änderungen (nicht am Code) tätigen.

Hierbei soll aufs Engste zusammengearbeitet werden. So eng diese Zusammenarbeit evtl. auch ist, so ist nicht zu verkennen, dass evtl. trotzdem die einzelnen Vertragsgegenstände isoliert zu sehen sind und der Systemcharakter aufgegeben wird. Falls später das Projekt "scheitert", ist nicht klar, welche Vorstufen davon ebenfalls einbezogen werden dürfen, wenn es um Schadenersatz oder Rückabwicklung geht.

Bei einem Kooperationsvertrag hinsichtlich eines neuartigen technischen Geräts kann der Vertrag evtl. auch einfach durch Ablauf der vereinbarten Zeit enden, der Entwickler aber auch schon vorher erkennen, dass er das Gerät nicht zu einem vermarktungsfähigen Zustand bringen wird. Innerhalb eines solchen Falles soll er verpflichtet sein, bei Vertragsende die jeweils erzielte Entwicklungsstufe zu übergeben, die bei pflichtgemäßem Einsatz bis zu diesem Zeitpunkt zu erreichen ist. Es wäre deshalb jeweils zu prüfen, ob nicht zugunsten von Kooperationsvorstellungen (die sich ebenfalls nachteilig für den Auftraggeber auswirken können) gleichzeitig eine Auflösung des Systemgedankens erfolgt.

So gesehen wäre "Projekt" Anlass, diese Zusammenhänge jeweils zu überprüfen und, wo notwendig, auch zum Vertragsgegenstand zu machen. Die Mitwirkungsleistungen des Auftraggebers sind lediglich im Bereich des Werkvertrages -und nur abstrakt - im BGB geregelt. Bei einem Dienstvertrag erübrigt sich diese Regelung aufgrund des Weisungsrechts des Dienstherrn. Über die Steuerung komplexer, langfristiger Verträge sagt das BGB nichts. Im Hinblick auf die Risikoverteilung (Projektverantwortung) ist es evtl. problematisch, für den Auftraggeber sogar schädlich, wenn er zu viele Möglichkeiten der Projektsteuerung in seiner Kompetenz behalten will. Diese ist nicht zu verwechseln mit der als Mitwirkung erforderlichen internen Projektorganisation beim Auftraggeber.

5. Änderung des Vertragstyps im Projektverlauf

Strebt der Auftraggeber einen Werkvertrag bzw. einen Leistungserfolg als Vertragsgegenstand an, behält sich aber alle möglichen Kompetenzen, das Projekt zu steuern, Einfluss zu nehmen, Weisungen zu geben, Änderungen vorzunehmen u. a., koordiniert er evtl. sogar mehrere Teams, an die Einzel-Werkverträge gegeben worden sind, kann sich der angestrebte Typ des Vertrags auch in einem Dienstvertrag zurückverwandeln.Tatsächlich versuchen naturgemäß viele Auftragnehmer, vor allem sehr große, die Verträge so auszugestalten, dass genau dieser Effekt eintritt, dass nämlich der Auftraggeber das Projekt steuert und somit ein Dienstvertrag daraus wird. Selbst wenn es aber bei dem Risiko-Schema des Werkvertrages verbleibt, versäumen es viele Auftragnehmer, die wichtigsten Eckpunkte des Vertrages auch zu ihren Gunsten zu handhaben, also vor allem die Bereitstellung des Pflichtenhefts, die späteren Mitwirkungsleistungen des Auftraggebers, dabei vor allem die Bereitstellung von Testdaten und evtl. notwendige Konkretisierungen des Pflichtenhefts.

Tipp: Sie haben Fragen zu dem Beitrag? Diskutieren Sie hierzu gerne mit uns in der Unternehmergruppe der IT-Recht Kanzlei auf Facebook.