Zur Bedeutung „der“ Dokumentation für IT-Projekte

Vertragsverhandlungen zu umfangreichen IT-Projekten sind häufig langwierig und nervenaufreibend. Denn regelmäßig müssen die stark gegenläufigen Interessen der Vertragsparteien unter einen Hut gebracht werden. Der Auftraggeber möchte in möglichst kurzer Zeit für möglichst wenig Geld eine Software, die alle seine Anforderungen erfüllt. Der Auftragnehmer sollte aufgrund seiner (Projekt-) Erfahrung wissen, dass diese Wünsche in der Realität nur schwer umzusetzen sein werden und er wird deshalb darauf bedacht sein Regelungen in den Vertrag einfließen zu lassen, die ihm einen gewissen (Handlungs-/Interessen-) Spielraum gewähren. In diesem Zusammenhang wird zu Unrecht die Frage, wann der Auftragnehmer welche Art von Dokumentation zu liefern hat, regelmäßig stark vernachlässigt. Welche unschönen Folgen ein solches Versäumnis haben kann, soll unter Bezugnahme auf eine Entscheidung des Landgerichts Wiesbaden vom 30. November 2016 (Az.: 11 O 10/15) erläutert werden.
 

Was war geschehen?

Der Auftraggeber wollte vom Auftragnehmer eine Internet-Plattform erstellen lassen, auf der ehemalige Soldaten mit potentiellen Arbeitgebern zusammengebracht werden sollten. Die Parteien des Rechtsstreits schlossen eine Absichtserklärung/einen Letter of Intent (LOI) ab. Der eigentliche Projektvertrag wurde fast vollständig ausgehandelt, dann aber von den Parteien nicht unterzeichnet. Nach dem Abschluss des LOI wurde jedoch bereits mit der Umsetzung des Projekts angefangen. Das Projekt sollte im sogenannten SCRUM-Verfahren umgesetzt werden. Das Projekt wurde dann vom Auftraggeber abgebrochen. Die Gründe dafür sind dem Urteil nicht klar zu entnehmen. Beim Rechtsstreit geht es um gegebenenfalls noch vom Auftraggeber an den Auftragnehmer zu zahlende Vergütung.
 

Die Entscheidung des Landgerichts Wiesbaden

Das Landgericht Wiesbaden hat entschieden, dass dem Auftragnehmer die von ihm geltend gemachten Vergütungsansprüche nicht zustehen. Maßgeblicher Grund für diese Entscheidung war die Tatsache, dass der vom Landgericht Wiesbaden hinzugezogene Sachverständige zu dem Ergebnis gekommen ist, dass die bisher vom Auftragnehmer erstellten Teile der Software unbrauchbar sind und der Auftraggeber deshalb Dritte nicht damit beauftragen kann die Software fertigzustellen. Aus der Sicht des Sachverständigen wird zur Fertigstellung der Software in jedem Fall die Hilfe des Auftragnehmers benötigt. Deshalb ist das Landgericht Wiesbaden zu der Überzeugung gelangt, dass die bisher vom Auftragnehmer gezahlte Vergütung ausreichend war.
 

Kritik am Urteil

Wenn man das Urteil aufmerksam liest stellt man sich an einigen Stellen die Frage, ob das Gericht den Sachverhalt vollständig erfasst hat. Beispielhaft soll angeführt werden, dass das Gericht davon ausgeht, dass der sogenannte SCRUM-Master dafür verantwortlich sein soll, dass das Projekt gelingt und die gewünschten Ergebnisse erreicht werden. Diese Auffassung dürfte jedoch schlichtweg falsch sein. Denn der SCRUM-Master hat vielmehr darauf zu achten, dass die am Projekt beteiligten Personen ihre nach dem SCRUM-Konzept auszufüllenden Rollen richtig wahrnehmen. Deshalb hat der SCRUM-Master neben projektleitenden gerade auch vermittelnde Funktionen inne und ist insofern nicht die „allein verantwortliche“ Person für das Gelingen des Projekts (siehe z.B.: http://scrum-master.de/Scrum-Rollen_ScrumMaster).

Unabhängig davon kann man sich jedoch auch die Frage stellen, ob das Landgericht Wiesbaden die bisher zu diesen Fragestellungen ergangene Rechtsprechung des Bundesgerichtshofs richtig berücksichtigt hat. Denn gerade die Frage, wann bei IT-Projekten der Auftragnehmer die Dokumentation bereitzustellen hat, hat der Bundesgerichtshof in einem Urteil vom 20. Februar 2001 (Az.: X ZR 9/99) eindeutig beantwortet. Danach schuldet der Auftragnehmer die für den Betrieb der Software erforderlichen Dokumentation erst mit dem Abschluss der Arbeiten an der Software. Wenn man davon ausgeht, dass diese Rechtsprechung weiterhin gültig ist und auch nicht zu erwarten ist, dass diese eine Änderung erfahren wird, kann man hier mit guten Gründen die Ansicht vertreten, dass man die Ablehnung der streitgegenständlichen Vergütungsansprüche des Auftragnehmers nicht auf das Fehlen einer Dokumentation stützen kann. Denn die Software war unstreitig nicht zu Ende entwickelt und der vorzeitige Abbruch des Projekts ist vom Auftraggeber veranlasst worden. Insofern konnte die fehlende Dokumentation eigentlich nicht das entscheidende Element für die Entscheidung dieses Rechtsstreits sein.

Unabhängig von der gerade geäußerten Kritik an der Begründung des Urteils bleibt festzustellen, dass trotz des vermeintlich positiven Ausgangs des Rechtsstreits für den Auftraggeber dieser ebenfalls als Verlierer dasteht. Denn er hat einen nicht unbeträchtlichen Betrag an den Auftragnehmer gezahlt und im Gegenzug dafür eine teilweise fertig gestellte Software erhalten, die er ohne Hilfe des Auftragnehmers auch nicht durch ein anderes Unternehmen fertigstellen lassen kann. Aufgrund der verhärteten Fronten ist auch nicht damit zu rechnen, dass die Parteien sich noch darauf einigen können, wie das Projekt erfolgreich zu Ende geführt werden kann.
 

Fazit

Aus der Sicht des Auftraggebers ist die Lieferung einer „allumfassenden“ Dokumentation regelmäßig eine Selbstverständlichkeit, die nicht weiter diskutiert muss und auch nicht gesondert zu vergüten ist. Im Gegensatz dazu ist den Auftragnehmern bekannt, dass die Erstellung von Dokumentationen unter Umständen viel Zeit in Anspruch nehmen kann. Insofern werden die dafür einzukalkulierenden Kosten häufig in der Gesamtkostenübersicht versteckt, um eventuellen Diskussionen vorzubeugen. Läuft das IT-Projekt dann aus dem Ruder und endet mit einem vorzeitigen Abbruch, so stellt sich die Frage ob und wenn ja, welche Art der Dokumentation geschuldet wird. In diesem Zusammenhang kann dann auch die Frage, mit welcher Methode das Projekt umgesetzt werden sollte, eine wichtige Rolle spielen. Denn unstreitig muss der Auftragnehmer, wenn nichts Besonderes vereinbart wurde, dem Auftraggeber ein Benutzerhandbuch/einer Anwenderdokumentation zur Verfügung stellen. Dieser Verpflichtung kann der Auftragnehmer nur durch den Abschluss einer Individualvereinbarung entgehen. Eine darüber hinausgehende Dokumentation, wie zum Beispiel eine Quellcode-Dokumentation, eine Beschreibung der Entwicklungsumgebung oder des Datenmodells wird regelmäßig nicht dazugehören. Diese Arten von Dokumentationen können jedoch gerade beim Abbruch eines IT Projekts für den Auftraggeber von entscheidender Bedeutung sein, ob dieser das Projekt mit einem anderen Anbieter erfolgreich zu Ende führen kann. Vor diesem Hintergrund sollten die Parteien genauer definieren welche Art der Dokumentation der Auftragnehmer zu welchem Zeitpunkt bereitzustellen hat. Wird zum Beispiel das SCRUM-Verfahren als Projektmethode verwendet, so sollte u.a. genau festgelegt werden, welche Dokumentation der Auftragnehmer hinsichtlich der einzelnen Sprints anzufertigen hat.

Aus den vorgenannten Gründen sollten die Parteien im Rahmen der Vertragsverhandlungen genau festlegen, welche Art der Dokumentation zu welchem Zeitpunkt geschuldet wird und welchen Aufwand der Auftragnehmer dem Auftraggeber dafür in Rechnung stellen kann. Denn es ist unrealistisch zu glauben, dass der Auftragnehmer eine ordentliche Dokumentation anfertigen wird, wenn der Auftraggeber nicht bereit ist hierfür ausreichende finanzielle Mittel zur Verfügung zu stellen. Auf der anderen Seite ist es für den Auftraggeber nicht ratsam aus Gründen der falschen Sparsamkeit gerade an diesem Punkt den Rotstift anzusetzen, wie der oben dargestellte Rechtsstreit eindrucksvoll nachweist. Deshalb sollten Auftraggeber auch nicht vereinbaren, dass das Benutzerhandbuch von Ihnen erstellt wird und der Auftragnehmer ihnen dabei nur assistiert. Die Mitarbeiter des Auftraggebers werden dieser Aufgabe häufig nicht gewachsen sein. Dies kann dann wiederum dazu führen, dass der Auftraggeber im schlechtesten Fall aus rechtlicher Sicht zu unrecht die im Rahmen der Erstellung des Benutzerhandbuchs erbrachten Beratungsleistungen des Auftragnehmers kritisiert und sich mit einem unzulänglichen Benutzerhandbuch zufrieden geben oder die Erstellung des Benutzerhandbuchs dann doch beim Auftragnehmer in Auftrag geben muss.
 

Sollte Ihnen der Artikel gefallen haben, so teilen Sie ihn doch bitte. Dafür können Sie die Buttons nutzen, die sich am Anfang des Artikels befinden.

Den Artikel können Sie auch als PDF-Dokument herunterladen:
Zur Bedeutung der Dokumentation für IT-Projekte

Ass. jur. Kai Riefenstahl
18.06.2017

gplus-profile-picture Verfasst von:

Ass. jur. Kai Riefenstahl

Schreibe den ersten Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.