Gescheitertes Softwareprojekt: Rechtliche Möglichkeiten

Ein Softwareprojekt, das ins Stocken gerät, ist ein schwerer Schlag für beide Seiten. Der Kunde hat in ein System investiert, das seine Abläufe optimieren soll, und muss nun zusehen, wie Fristen verstreichen, ohne dass ein funktionierendes Ergebnis vorliegt. Der Anbieter hingegen sieht oft ein anderes Bild: einen Kunden, der ständig neue Wünsche äußert, Entscheidungen hinauszögert oder zu wenige Informationen liefert.

Wer trägt also den Verlust? Vier Punkte vorab:

Ein gescheitertes Softwareprojekt bedeutet nicht automatisch ein Versagen des Lieferanten.
Die Mitwirkung des Kunden kann auch rechtlich relevant sein.
Eine gute Projektdokumentation und vertragliche Vereinbarungen begrenzen das Prozessrisiko.
Eine Expertenuntersuchung kann für die technische Beurteilung entscheidend sein.

Im Folgenden gehen wir nacheinander auf die häufigsten Ursachen, die rechtliche Beurteilung, die Mitwirkungspflicht des Mandanten, die Sachverständigenuntersuchung, die möglichen Ergebnisse des Verfahrens, was praktische Beispiele zeigen und welche Maßnahmen einem Streit vorbeugen können.

Häufige Ursachen

Eine Handvoll Ursachen tritt in der Praxis immer wieder auf.

Scope Creep, die schleichende Ausweitung des Auftrags. Die Anforderungen an das System wachsen stetig, ohne dass ein formelles Änderungsverfahren existiert, das die Folgen für Planung und Budget berücksichtigt.
Unklare oder unvollständige Funktionsspezifikationen. Wenn nicht im Voraus festgelegt wird, was das System leisten soll, wird es später zu Streitigkeiten darüber kommen, ob das gelieferte Ergebnis den Anforderungen entspricht.
Mangelhaftes Systemdesign. Die Architektur ist weder für die tatsächliche Last noch für die Schnittstellen zu anderen Systemen oder zukünftige Erweiterungen ausgelegt.
Unterschätzung der Komplexität und der Vorlaufzeit, insbesondere bei Projekten, bei denen mehrere bestehende Systeme miteinander verbunden werden müssen.
Verspätete oder eingeschränkte Kooperation seitens des Kunden.

Diese Ursachen treten selten isoliert auf. Sie verstärken sich oft gegenseitig. Ein Projekt, das sich anfänglich nur verzögert, kann deshalb möglicherweise vollständig scheitern.

Rechtliche Beurteilung: Nichterfüllung und Mitverschulden

Die erste Rechtsfrage ist, ob dem Lieferanten ein zurechenbarer Vertragsbruch vorliegt. Artikel 6:74 des niederländischen Bürgerlichen Gesetzbuches verpflichtet den Schuldner zum Ersatz des dem Gläubiger durch die Nichterfüllung entstandenen Schadens, es sei denn, der Vertragsbruch ist ihm nicht zurechenbar.

Für eine erfolgreiche Reklamation muss daher nachgewiesen werden, dass der Lieferant die vereinbarte Leistung nicht erbracht hat, beispielsweise weil die Software nicht den dokumentierten Funktionsspezifikationen entspricht. Der Mangel muss zudem auf den Lieferanten zurückzuführen sein, höhere Gewalt darf also nicht vorliegen.

In der Praxis ist die Verantwortung oft geteilt. Der Kunde hat bestimmte Anforderungen erst spät präzisiert, seine Wünsche während des Projekts geändert, ohne die Konsequenzen für Planung und Kosten zu akzeptieren, oder keine brauchbare Testumgebung zur Verfügung gestellt.

In einem solchen Fall kann das Gericht die Schadensersatzpflicht des Lieferanten gemäß Artikel 6:101 des niederländischen Bürgerlichen Gesetzbuches im Verhältnis zu dem Anteil der dem Kunden zuzurechnenden Umstände kürzen. Diese Mitschuldregelung kann eine Entschädigung erheblich reduzieren und in Ausnahmefällen sogar zu deren vollständiger Aufhebung führen.

Praktischer Tipp für beide Parteien: Dokumentieren Sie während des gesamten Projekts, wer welche Entscheidungen trifft, welche Änderungen vorgenommen werden und welche Informationen wann bereitgestellt werden. In Gerichtsverfahren kann diese Dokumentation oft den Unterschied zwischen voller Haftung und einem deutlich milderen Ausgang ausmachen.

Die Pflicht des Kunden zur Mitwirkung

Die Implementierung einer Software ist ein Gemeinschaftsprojekt. Der Anbieter entwickelt und konfiguriert die Software, ist aber kontinuierlich auf den Kunden angewiesen: zeitnahe und vollständige Spezifikationen, brauchbare Testdaten, zügige Entscheidungen bei offenen Fragen und die rechtzeitige Abnahme der gelieferten Komponenten.

Fehlt diese Mitwirkung, kann der Lieferant seine Leistungen nicht erbringen. Dies hat gesetzliche Konsequenzen. Artikel 6:58 ff. des niederländischen Bürgerlichen Gesetzbuches regelt den Zahlungsverzug des Gläubigers, der eintritt, wenn die Leistung des Schuldners aufgrund der fehlenden Mitwirkung des Gläubigers nicht erbracht werden kann.

In der Praxis bedeutet dies: Verzögert sich der Lieferant, weil der Kunde die benötigten Leistungen nicht rechtzeitig bereitstellt, gerät der Lieferant nicht in Verzug und haftet nicht für die Verzögerung. Der Kunde selbst kann in Verzug geraten. Da Softwareprojekte in der Regel iterativ ablaufen und jede Phase auf dem Feedback und der Genehmigung der vorherigen aufbaut, wird fehlendes Feedback in der Rechtsprechung regelmäßig herangezogen, um Verzögerungen ganz oder teilweise dem Kunden zuzuschreiben.

Für Kunden ist folgender Punkt wichtig: Kritik am Projektfortschritt hat wenig Gewicht, wenn die eigenen Entscheidungen langsam sind. Für Lieferanten gilt das Gegenteil: Verzögerungen, die dem Kunden zuzuschreiben sind, müssen unverzüglich und schriftlich gemeldet werden, beispielsweise durch eine klare Warnung oder eine Mahnung, sobald die erforderlichen Leistungen ausbleiben. Geschieht dies nicht, lässt sich im Nachhinein oft nicht mehr feststellen, wer welche Verzögerung verursacht hat.

Die Expertenuntersuchung

Softwareprojekte sind technischer Natur. Entsprach die gelieferte Software den Spezifikationen? Lag die Verzögerung beim Lieferanten oder beim Kunden? Waren die in Rechnung gestellten Mehrarbeiten gerechtfertigt? Fragen zur Architektur, zum Quellcode, zur Nachvollziehbarkeit der Anforderungen im Entwicklungsprozess und zum Inhalt von Testberichten erfordern technisches Fachwissen, das von einem Richter nicht erwartet werden kann.

Aus diesem Grund wird in solchen Streitigkeiten häufig ein gerichtlich angeordnetes Sachverständigengutachten gemäß den Artikeln 194 bis 207 der niederländischen Zivilprozessordnung in Auftrag gegeben. Ein unabhängiger Sachverständiger beurteilt dann, ob die Software den vereinbarten Bedingungen entsprach, wo die Verzögerung entstand und ob die entstandenen Kosten angemessen waren. In der Praxis hat das Ergebnis maßgeblichen Einfluss auf das Urteil des Gerichts.

Ein Sachverständiger benötigt in der Regel folgende Dokumente:

der Vertrag und seine Anhänge;
die funktionalen und technischen Spezifikationen;
die Änderungsanträge;
die Projektplanung und Fortschrittsberichte;
die Testberichte;
die Korrespondenz über Verzögerungen und Annahme;
den Quellcode und die Dokumentation.

Fehlt ein Teil dieser Unterlagen, kann der Sachverständige die Frage oft nicht beantworten. Dies wirkt sich auf die Beweislage der Partei aus, die sich auf diese Fakten beruft. Daher lohnt es sich, diese Unterlagen während des gesamten Projekts ordentlich zu führen, nicht erst, wenn ein Streitfall entstanden ist.

Mögliche Ergebnisse des Verfahrens

Wenn nur ein Teil des Vertrags nicht erfüllt ist, beispielsweise weil ein Modul nicht funktioniert, die übrigen jedoch nutzbar sind, kann das Gericht gemäß Artikel 6:265 in Verbindung mit Artikel 6:270 des niederländischen Bürgerlichen Gesetzbuches eine teilweise Aufhebung anordnen. Der erfolgreiche Teil bleibt dann bestehen.

Schadensersatz kann auch gemäß Artikel 6:74 zugesprochen werden, der jedoch gemäß Artikel 6:101 wegen Mitverschuldens gekürzt werden kann. Schließlich kann das Gericht den Schadensersatz gemäß Artikel 6:109 mindern, beispielsweise wenn der geltend gemachte Betrag in keinem Verhältnis zum ursprünglichen Vertragswert steht. Gerichte nutzen diese Minderungsmöglichkeit jedoch nur zurückhaltend.

In der Praxis endet ein gescheitertes Softwareprojekt oft mit einem Neustart bei einem anderen Anbieter. Auch das verläuft selten ohne Diskussionen. Wer erhält den Quellcode? Wem gehören die Rechte am geistigen Eigentum des entwickelten Systems? Gibt es eine Treuhandvereinbarung, bei der der Quellcode bei einem unabhängigen Dritten hinterlegt wird? Wer all das nicht von Anfang an geklärt hat, merkt es genau in diesem Moment.

Was zeigen praktische Beispiele?

Neben den ordentlichen Gerichten spielt die Stiftung zur Beilegung von Automatisierungsstreitigkeiten (SGOA) eine wichtige Rolle im IT-Sektor. Dieses unabhängige Streitbeilegungsinstitut besteht seit 1989 und bietet Mediation, Schiedsverfahren, summarische Schiedsverfahren, verbindliche Gutachten, Sachverständigengutachten und Konfliktprävention an. Die Schiedsrichter sind Branchenexperten, weshalb viele IT-Streitigkeiten auf diesem Weg und nicht vor Gericht beigelegt werden.

Die veröffentlichten SGOA-Entscheidungen offenbaren einige wiederkehrende Lehren, die auch außerhalb von Gerichtsverfahren nützlich sind:

Die Verantwortung wird selten allein einer Partei zugeschrieben; die Zuweisung ergibt sich aus dem, was jede Partei tatsächlich getan und unterlassen hat.
Zu den häufigsten Streitpunkten zählen Spezifikationen, die sich im Laufe des Projekts ändern, und das Fehlen eines formellen Änderungsverfahrens wirkt sich in der Regel negativ auf die Partei aus, die sich auf die ursprüngliche Vereinbarung beruft.
Die Qualität der Projektdokumentation ist oft entscheidend, denn sie bestimmt, welche Fakten noch ermittelt werden können.

Für jeden, der einen Vertrag aufsetzt, sind dies nützliche Hinweise: Es handelt sich genau um die Punkte, die am besten im Voraus geklärt werden.

Vorsichtsmaßnahmen

Viele Streitigkeiten lassen sich durch die richtige Vertragsgestaltung vermeiden.

Arbeiten Sie mit phasenweisen Verträgen. Teilen Sie das Projekt in Releases oder Meilensteine auf, von denen jeder seine eigenen Abnahmekriterien hat. Dadurch vermeiden Sie eine Gesamtbewertung erst nach Monaten.
Vor der Rechnungsstellung sollten formale Abnahmetests vereinbart werden. Dadurch wird festgelegt, welche Anforderungen eine gelieferte Komponente erfüllen muss, bevor die Zahlung fällig wird.
Erstellen Sie ein Änderungsverfahren, in dem festgelegt ist, wer eine Änderung beantragen kann, wer darüber entscheidet und wie die Auswirkungen auf Planung und Preisgestaltung verarbeitet werden.
Eine Eskalationsstufe vereinbaren: zuerst eine Diskussion innerhalb der Projektgruppe, dann ein Lenkungsausschuss auf höherer Ebene, dann ein Mediator und erst dann ein Verfahren vor Gericht.
Ziehen Sie eine Streitbeilegung über die SGOA in Betracht. Beachten Sie dabei einen wichtigen Punkt: Schiedsrichter können nur Fälle verhandeln, in denen die Parteien der Stiftung im Voraus die Zuständigkeit übertragen haben; diese Klausel muss also im Vertrag enthalten sein. Die SGOA stellt hierfür Musterklauseln zur Verfügung.

Ein Eskalationsverfahren stellt sicher, dass Konflikte frühzeitig und auf der richtigen Ebene besprochen werden, anstatt erst, wenn die Beziehungen bereits zerbrochen sind. In Situationen, in denen ein Projekt an einem kritischen Punkt ins Stocken gerät und eine Partei die Kooperation verweigert, bieten die summarischen Schiedsverfahren der SGOA schnelle Abhilfe.

Zum Schluss

Ein gescheitertes Softwareprojekt ist selten auf einen einzelnen Fehler zurückzuführen. Meist entsteht es durch eine Kombination aus unklaren Spezifikationen, sich ändernden Wünschen, technischer Fehleinschätzung und mangelnder Zusammenarbeit. Das niederländische Recht bietet einen differenzierten Rahmen zur Bestimmung der Schadensverantwortlichkeit – sei es bei Nichterfüllung, Mitverschulden oder Zahlungsausfall des Gläubigers. Dessen Anwendung erfordert jedoch Kenntnisse sowohl des Rechts als auch der Technologie.

Steckt Ihr Softwareprojekt ins Stocken? Law & More Wir beraten Kunden und Lieferanten zu Haftungsfragen, Projektdokumentation, Vertragsvermeidung und Streitbeilegung. Kontaktieren Sie uns für eine Prüfung Ihres Vertrags und Ihrer Projektakte.

Häufig gestellte Fragen

Im Folgenden beantworten wir die am häufigsten gestellten Fragen zu diesem Thema.

Haftet mein Lieferant, wenn das Softwareprojekt scheitert?

Nicht automatisch. Es muss nachgewiesen werden, dass die vereinbarten Leistungen nicht erbracht wurden und dies auf das Konto des Unternehmens geht. In der Praxis wird die Verantwortung häufig zwischen beiden Parteien geteilt.

Was wäre, wenn ich als Kunde selbst zu der Verzögerung beigetragen hätte?

Das Gericht kann die Entschädigungspflicht des Lieferanten gemäß Artikel 6:101 des niederländischen Bürgerlichen Gesetzbuches entsprechend dem Anteil Ihres eigenen Verhaltens am Schaden mindern. Dies kann die Entschädigungssumme erheblich reduzieren und in Ausnahmefällen zu deren Aufhebung führen.

Was beinhaltet die Pflicht zur Zusammenarbeit?

Als Auftraggeber müssen Sie Spezifikationen, Testdaten, Entscheidungen und Abnahmen rechtzeitig übermitteln. Geschieht dies nicht und kann der Lieferant seine Leistungen infolgedessen nicht erbringen, gerät er nicht in Verzug, und Sie selbst können in Gläubigerverzug geraten (Artikel 6:58 ff. des niederländischen Bürgerlichen Gesetzbuches).

Warum wird häufig ein Experte hinzugezogen?

Da Fragen zur Architektur, zum Quellcode und zu Testberichten technisches Fachwissen erfordern, das von einem Richter nicht erwartet werden kann, kann gemäß den Artikeln 194 bis 207 der niederländischen Zivilprozessordnung ein gerichtlich angeordnetes Sachverständigengutachten in Auftrag gegeben werden, dessen Ergebnis erhebliches Gewicht hat.

Welche Projektdokumente sollte ich aufbewahren?

Der Vertrag mit seinen Anhängen, die funktionalen und technischen Spezifikationen, die Änderungsanträge, die Projektplanung und die Fortschrittsberichte, die Testberichte, die Korrespondenz zu Verzögerungen und Abnahmen sowie der Quellcode mit Dokumentation. Ohne diese Dokumente kann ein Experte die Frage oft nicht beantworten.

Warum ist ein Änderungsverfahren so wichtig?

Ohne ein formelles Verfahren wächst der Umfang des Auftrags unbemerkt an, während Planung und Budget unverändert bleiben. Im Streitfall lässt sich dann nicht mehr feststellen, wann und warum sich der Umfang geändert hat. Dokumentieren Sie, wer eine Änderung beantragen kann, wer die Entscheidung trifft und wie die Auswirkungen auf Planung und Preis gehandhabt werden.

Welchen Sinn haben Akzeptanzkriterien?

Sie legen objektiv fest, wann eine gelieferte Komponente den Anforderungen entspricht. Dadurch wird klar, wann die Zahlung fällig ist, und spätere Streitigkeiten über die ordnungsgemäße Lieferung werden weitgehend vermieden. Idealerweise sollten sie an Releases oder Meilensteine mit formalen Abnahmetests gekoppelt werden.

Was geschieht mit dem Quellcode bei einem Neustart mit einem anderen Anbieter?

Das hängt von Ihrem Vertrag ab. Ohne Vereinbarungen zur Freigabe des Quellcodes, zu den Rechten an geistigem Eigentum des entwickelten Systems und zu etwaigen Treuhandvereinbarungen kann sich ein Neustart erheblich verzögern. Klären Sie dies bei Vertragsabschluss, nicht erst im Nachhinein.

Welche Ergebnisse kann das Verfahren haben?

Teilweise Aufhebung, wenn nur ein Teil des Vertrags fehlerhaft ist (Artikel 6:265 in Verbindung mit Artikel 6:270 des niederländischen Bürgerlichen Gesetzbuches), Schadensersatz nach Artikel 6:74, Minderung wegen Mitverschuldens nach Artikel 6:101 und Milderung nach Artikel 6:109. Die Gerichte wenden diese Milderung nur zurückhaltend an.

Kann ich einen Streitfall außergerichtlich beilegen?

Ja. Die SGOA bietet Mediation, Schiedsverfahren, summarische Schiedsverfahren, verbindliche Beratung und Gutachten an, wobei Branchenexperten die Entscheidungen treffen. Schiedsrichter können nur Fälle verhandeln, in denen die Parteien der Stiftung im Voraus die Zuständigkeit übertragen haben; daher sollte diese Klausel in den Vertrag aufgenommen werden.

Wie kann ich einen langwierigen Streit vermeiden?

Arbeiten Sie mit phasenweisen Verträgen und Abnahmekriterien pro Release, vereinbaren Sie formale Abnahmetests vor der Rechnungsstellung, dokumentieren Sie ein Änderungsverfahren und vereinbaren Sie eine Eskalationsleiter, die von der Projektgruppe über den Lenkungsausschuss und den Mediator bis hin zu Gerichtsverfahren reicht.

Haben Sie eine Auseinandersetzung mit einem IT-Lieferanten oder möchten Sie einen IT-Vertrag überprüfen lassen? Unsere IT-Anwälte helfen Ihnen gerne.

Wie Law & More Wie wir Ihnen dabei helfen können, wird auf unserer Website erklärt. IT-Anwalt