Prozesse um gescheiterte IT-Projekte – wie ist die Beweislast verteilt?

Wenn IT-Projekte scheitern, kann es sein, dass der Konflikt erst vor Gericht endet. In diesem Beitrag erklären wir, welche Rolle hier und schon im Vorfeld die Darlegungs- und Beweislast spielt, welche Tücken sich aus Agilen Projekten ergeben und welche Praxistipps wir für Konfliktfälle um IT-Projekte haben.

IT-Projekte in Schieflage

Auch wenn das inzwischen weit verbreitete „agile“ Vorgehen die Erfolgsbilanz von IT-Projekten tendenziell verbessert hat, scheitert nach wie vor eine erhebliche Zahl von Projekten. In der Folge streiten sich die Beteiligten sehr häufig um die Verantwortlichkeit für das Scheitern und um den Ausgleich für die auf beiden Seiten erlittenen Nachteile.

In den letzten Jahren hatten wir bei comp/lex immer wieder mit Konflikten um gescheiterte IT-Projekte zu tun, wobei wir sowohl Anbieter:innen als auch Kund:innen beraten und vertreten haben, auch vor Gericht. Für die Beratung zu Beginn eines Konflikts ist es wichtig, einschätzen zu können und zu planen, wie hoch in einem späteren Gerichtsverfahren die Erfolgschancen wären. Denn diese Einschätzung hat schon erhebliche Auswirkungen darauf, wie mutig man in außergerichtliche Verhandlungen gehen sollte.

Aus einigen Fällen unserer Beratungspraxis haben wir inzwischen gelernt, wie entscheidend hier eine realistische Einschätzung der Beweislage im Gerichtsverfahren ist.

Was bedeutet Darlegungs- und Beweislast?

Nach einem gescheiterten IT-Projekt streiten sich die Parteien meist darum, was tatsächlich passiert ist: War das bereitgestellte Ergebnis tatsächlich so weit weg vom vereinbarten Ergebnis, wie die Kundin oder der Kunde es behauptet? Welches Ergebnis war überhaupt vereinbart? Was hätte die Kundin bzw. der Kunde selbst beitragen müssen und inwieweit hat sie/er das nicht getan? Welche Fristen gab es, wurden sie eingehalten, und falls nicht, warum nicht?

Schon im außergerichtlichen Stadium der Konfliktlösung tragen sich die Beteiligten ihre Sicht auf den Fall gegenseitig vor. Das geschieht mal mehr mal weniger vollständig und mal mehr mal weniger professionell und sachlich. Aus rechtlicher Sicht ist das aber gar nicht unbedingt entscheidend – Hauptsache, man bekommt eine gute Einigung hin. Auch hier kann anwaltliche Unterstützung helfen, sowohl bei dem Entwurf von Schriftsätzen, bei der Verhandlung und nicht zuletzt bei der Formulierung von Vergleichsangeboten und -vereinbarungen. Aber jetzt beschäftigen wir uns mit dem Fall, dass der außergerichtliche Vergleich scheitert und es vor Gericht geht.

Die Darlegungs- und Beweislast im gerichtlichen Verfahren

Hier tauschen die Parteien zunächst ihre Ansprüche in Form von Anträgen schriftlich aus, bevor das Gericht zum Fall Stellung nimmt und die ersten Entscheidungen trifft. Jetzt spielt die so genannte Darlegungs- und Beweislast häufig eine entscheidende Rolle. Was heißt das?

Unter Darlegungs- und Beweislast versteht man die Verpflichtung einer Partei, in einem Prozess bestimmte Sachverhalte vorzutragen und deren Wahrheit zu beweisen, wenn die Gegenseite den Sachverhalt bestreitet. Bestreitet die Gegenseite einen Sachverhalt nicht (oder, ein etwas komplizierterer Fall, in unzulässiger Art und Weise), gilt er als zugestanden. Das Gericht nimmt dann also an, dass das, was eine Partei vorträgt, auch wahr ist.

Im Zivilprozess trägt grundsätzlich derjenige, der vom Gericht etwas will, die Beweislast für die tatsächlichen Voraussetzungen seines Anspruchs. Darlegungslast bedeutet, die notwendigen Tatsachen überhaupt erst einmal substantiiert (also mit ausreichender Genauigkeit und Detailtiefe) vorzutragen (also dem Gericht zu „erzählen“), während die Beweislast meint, diesen Vortrag auch mit Beweismitteln zu untermauern. Gelingt der beweisbelasteten Partei der Nachweis nicht, verliert sie den Prozess hinsichtlich dieses Punkts – das Gericht behandelt die unbeweisbare Behauptung dann als unzutreffend. Kurz gesagt: „Recht haben“ genügt nicht – man muss es auch beweisen können.

Die obige Regel zur Darlegungs- und Beweislast hört sich zunächst einfach an, es kann im Prozess trotzdem schnell unklar sein und zu Diskussionen führen, wer für welche Aspekte eines Falls die Darlegungs- und Beweislast trägt. Man unterscheidet dann anspruchsbegründende, anspruchsvernichtende und anspruchshindernde Tatsachen.

Ein einfacher Beispielfall: Unternehmen A verklagt Unternehmen B auf Zahlung aus einem Vertrag über Softwaremiete. B verweigert die Zahlung mit der Behauptung, das Unternehmen hätte den Vertrag zu einem bestimmten Zeitpunkt gekündigt. In einem Prozess hätte A die Darlegungs- und Beweislast für die Tatsache, dass A und B einen laufenden Vertrag (ein sog. Dauerschuldverhältnis) geschlossen haben. B wiederum hat die Darlegungs- und Beweislast für den Sachverhalt, der die wirksame Kündigung begründet.

Die Abnahme als Wendepunkt

Im Zusammenhang mit IT-Projekten ist die Sache noch etwas komplizierter. Hier geht es meist darum, dass das Projekt schon in der Entwicklungsphase nicht so voran kommt, wie von den Parteien gewünscht. Zu einem bestimmten Zeitpunkt reicht es einer Seite dann, und sie bricht das Projekt ab. Meist ist das die Kundin/der Kunde, und von diesem Fall sprechen wir jetzt auch vor allem.

Häufig ist es so, dass die Anbieterin/der Anbieter zu diesem Zeitpunkt noch gar nicht so weit ist, der Kundin/dem Kunden das Projekt zur Abnahme bereit zu stellen. Oder sie/er tut es zwar, die Kundin/der Kunde ist jedoch enttäuscht vom Ergebnis und verweigert die Abnahme, unter Umständen auch mehrfach und irgendwann endgültig. Sie/er erklärt das Projekt dann für gescheitert und macht Ansprüche geltend. Das können bereits gezahlte Vergütungen sein, aber auch der Ersatz eigener Aufwendungen und/oder Kosten für ein Folgeprojekt.

Was bedeutet das nun für die Darlegungs- und Beweislast? Es ist so: In der geschilderten Situation trägt vor der Abnahme in der Regel die Anbieterin bzw. der Anbieter die Darlegungs- und Beweislast dafür, dass die Ergebnisse abnahmefähig waren. Das bedeutet zugleich, dass sie/er darlegen und beweisen muss, dass die Ergebnisse zum Zeitpunkt der gewünschten Abnahme im Wesentlichen der vertraglichen Vereinbarung entsprochen haben.

Platzt das Projekt erst nach erfolgter Abnahme (zum Beispiel, weil die Anbieterin/der Anbieter nicht in der Lage ist, nicht abnahmehindernde Mängel zu beseitigen, oder weil sich nach der Abnahme weitere Mängel gezeigt haben), dreht sich der Spieß um, und die Kundin/der Kunde muss etwaige Mängel darlegen und beweisen.

Warum kann der Beweis so schwierig sein?

Was heißt es nun zum Beispiel für die Anbieterin/den Anbieter konkret, wenn sie/er die Darlegungs- und Beweislast für ein abnahmefähiges Ergebnis hat?

Es heißt, dass sie/er folgende Tatsachen darlegen und beweisen muss:

1. Den vereinbarten Leistungsumfang, also z.B. die Funktionalitäten der zu entwickelnden Software;

2. ein Ergebnis zum fraglichen Zeitpunkt (z.B. zum Abnahmetermin), das im Wesentlichen dem vereinbarten Leistungsumfang entspricht.

Es liegt auf der Hand, dass es schon einen gewissen Aufwand erfordert, diese Tatsachen in einem Gerichtsverfahren vorzutragen. Sie zu beweisen, ist dann noch einmal aufwändiger, es läuft in der Regel nichts über umfangreiche und teure Sachverständigengutachten. Diese Gutachten kosten jede Menge Geld, das die beweisbelastete Partei vorschießen muss.

Für die Anbieter:innen-Seite bedeutet das: Gründliche Dokumentation ist Gold wert. Lasten- und Pflichtenhefte, Abnahmeprotokolle, Testergebnisse (falls die Abnahmeprüfung schon begonnen wurde) – all das sollte vorhanden sein, um im Ernstfall belegen zu können, dass man die vereinbarten Anforderungen erfüllt hat. Gerade bei komplexen IT-Projekten ist es für Auftragnehmer:innen essenziell, jede erfüllte Anforderung nachweisbar zu machen (etwa durch Zwischenabnahmen oder Abnahmetests), solange die Abnahme noch aussteht.

Probleme im Agilen Projekt

Agile Methoden wie Scrum gelten als Heilsbringer für flexibles Projektmanagement – sie erlauben laufende Änderungen der Anforderungen und geben entsprechend Flexibilität in der Entwicklung. Außerdem machen Sie Projekte möglich, in denen das Zielergebnis zu Beginn noch gar nicht feststeht. Doch diese Flexibilität hat juristische Kehrseiten, vor allem bei der Darlegungs- und Beweislast.

Denn: Wie weist man vor Gericht nach, dass man ein „abnahmefähiges Werk“ geliefert hat, wenn sich die Zielvorgaben ständig geändert haben? Je dynamischer das Projekt, desto schwieriger lässt sich im Nachhinein festnageln, welcher konkrete Leistungsumfang eigentlich geschuldet war und ob dieser erreicht wurde. Die klassische Beweislastregel (Anbieter:in muss bis zur Abnahme die Vertragsgemäßheit beweisen) bleibt nach geltender Rechtsprechung zwar auch bei einem agilen Projekt bestehen – aber die Unschärfe im Anforderungsprofil erschwert diesen Nachweis erheblich.

Interessant ist auch ein anderer Aspekt: Agile Verträge werfen die Frage auf, ob überhaupt ein Werkvertrag (Erfolg geschuldet) oder eher ein Dienstvertrag (Tätigkeit geschuldet) vorliegt. Wenn nichts Konkretes als Erfolg vereinbart ist außer einem „Bemühen“, könnte man argumentieren, es handle sich nicht um einen klassischen Werkvertrag. Wir bei comp/lex halten das bei einem kollaborativ gelebten agilen Projekt für gut vertretbar.

Beide Parteien sollten daher bei agilen Projekten ein Interesse daran haben, klare Definition-of-Done-Kriterien und Freigabekriterien zu vereinbaren. Für die Kund:innen ist das wichtig, um sich vor der Konstellation des Scheiterns nach Abnahme zu schützen.

Rückzahlung oder Schadensersatz? – Mögliche Ansprüche bei gescheiterten IT-Projekten

Wenn ein IT-Projekt scheitert, stellt sich für die/den geschädigten Vertragspartner:in (meist die Kundin/der Kunde) die Frage: Was kann ich eigentlich verlangen? Grundsätzlich kommen zwei Anspruchsgrundlagen in Betracht, abhängig davon, wie man mit dem gescheiterten Vertrag umgeht:

Rückabwicklung des Vertrags (Rücktritt): Die Kundin/der Kunde tritt vom Vertrag zurück und verlangt Rückzahlung bereits gezahlter Vergütungen. Beide Seiten sollen dann so gestellt werden, als hätte es den Vertrag nie gegeben – die Anbieterin/der Anbieter müsste also das bereits erhaltene Geld erstatten, die Kundin/der Kunde im Gegenzug die empfangene (wenn auch unvollständige oder mangelhafte) Leistung zurückgeben bzw. nicht weiter nutzen. Dieses Szenario kommt oft in Frage, wenn vor Abnahme Schluss ist und die Kundin/der Kunde das halbfertige oder mangelhafte Werk nicht gebrauchen kann. Juristisch spricht man hier vom Rücktritt und Ansprüchen aus einem Rückgewährschuldverhältnis. Im Mittelpunkt steht hier in aller Regel die Rückzahlung bereits gezahlter Vergütungen.

Schadensersatz (neben der Leistung): Alternativ kann die Kundin/der Kunde Schadensersatz neben der Leistung verlangen. Das heißt, die Kundin/der Kunde behält (und bezahlt) die bisherigen Projektergebnisse und fordert Ersatz für finanzielle Verluste, die durch das Scheitern des Projekts entstanden sind. Typischerweise sind das Mehrkosten, etwa weil ein:e Ersatz-Dienstleister:in beauftragt werden musste, um das Projekt zu retten, oder weil das Projektverzögerungen verursacht hat.

Beide Ansätze können zum Teil auch kombiniert werden, aber eben nicht komplett – sie sind juristisch genau abzugrenzen. Beispielsweise kann eine Kundin/ein Kunde nach Rücktritt die gezahlten Vergütungen zurückverlangen und zusätzlich Schadensersatz fordern, wenn ihr/ihm durch das Scheitern weitere Kosten entstanden sind – allerdings darf sie/er am Ende nicht besser dastehen als vor dem Vertrag.

Praxis-Tipp: Realistisch einschätzen und außergerichtliche Lösungen prüfen

Rechtsstreitigkeiten um gescheiterte IT-Projekte sind hochkomplex, zeitaufwändig und teuer – oft gibt es am Ende keinen klaren Gewinner. Beide Seiten sollten sich von Anfang an klar machen, dass ein Gerichtsverfahren viel Kapazität bindet und das Ergebnis ungewiss ist. Die Darlegungs- und Beweislast kann häufig den Fall entscheiden oder ihm zumindest eine Tendenz geben: Wer die besseren Beweise hat und seine Geschichte schlüssig erzählen kann, hat die Nase vorn.

Daher unser dringender Rat an IT-Anbieter:innen wie auch Kund:innen:

1. Dokumentieren, dokumentieren, dokumentieren! Halten Sie während des Projekts alles Relevante schriftlich fest – Anforderungen, Änderungen (Change Requests), Zwischenabnahmen, Mängelanzeigen, Protokolle von Meetings. Jedes Dokument kann im Streitfall zum entscheidenden Beweisstück werden. Im Nachhinein rekonstruierte Behauptungen ohne Belege haben dagegen vor Gericht einen schweren Stand.

2. Verträge sauber gestalten: Sorgen Sie dafür, dass der Vertrag klare Regelungen zur Abnahme, zum Leistungsumfang und zu Änderungsverfahren enthält. Unklare oder lückenhafte Verträge sind Einfallstore für Interpretationsstreitigkeiten. Investieren Sie lieber früh in eine gute Vertragsgestaltung, um späteren Ärger zu vermeiden. Allerdings muss Ihnen klar sein, dass ein guter Vertrag nicht automatisch zu einem guten Projekt führt.

3. Realistisch beraten lassen: Lassen Sie Ihre Prozesschancen von einer erfahrenen IT-Kanzlei einschätzen, bevor Sie über die weitere Strategie entscheiden. Eine gute Anwältin/ein guter Anwalt kann anhand der Beweislage und Vertragssituation oft relativ gut prognostizieren, wer die Beweislast trägt und wie schwer diese Last wiegt. So können Sie besser abwägen, welche Chancen Sie vor Gericht hätten und was das für vorgelagerte Vergleichsverhandlungen bedeutet.

4. Außergerichtliche Lösungen prüfen: Scheuen Sie nicht den Vorschlag eines vergleichsweisen Kompromisses. Oft lassen sich durch einen Vergleich kreative Lösungen finden, bei denen z.B. die Anbieterin/der Anbieter der Kundin/dem Kunden noch entgegenkommt (finanziell oder durch Nachbesserung), und die Kundin/der Kunde im Gegenzug auf weitere Ansprüche verzichtet. Das spart beiden Seiten Nerven, Geld und Imageverlust. (Teil eines Vergleichs kann dann auch die Verschwiegenheit über das gescheiterte Projekt sein – was beiden Seiten das Gesicht wahrt.)

Fazit

Die Erfolgschancen bei IT-Projektstreitigkeiten hängen weniger von der emotionalen Überzeugung ab, im Recht zu sein, sondern vielmehr von harten prozessualen Fakten: Wer muss was beweisen können? Wenn Sie frühzeitig verstehen, auf wessen Seite die Darlegungs- und Beweislast liegt und ob Sie dieser Last gewachsen sind, können Sie strategisch klüger handeln. IT-Dienstleister:innen sollten sich der Risiken vor Abnahme bewusst sein und ihre Arbeit belegbar machen; IT-Kund:innen sollten wissen, dass mit der Abnahme eine wichtige Beweislastumkehr erfolgt.

Beide Seiten tun gut daran, Streitprävention durch klare Verträge und saubere Projektführung zu betreiben – dann steigen die Chancen, dass das IT-Projekt gar nicht erst vor Gericht endet, sondern trotz aller Widrigkeiten noch zu einem erfolgreichen Ende geführt werden kann.