IT Abnahme

Wenn IT-Projekte scheitern: Welche Gestaltungsmöglichkeiten es für den Worst Case gibt.

Große Erwartungen beim Auftraggeber, viele Versprechungen beim Anbieter: Waren sich die Partner beim Vertragsabschluss noch überzeugt davon, sich über Ziele und Weg des neuen IT-Projekts einig zu sein, sieht es bei der Umsetzung häufig anders aus: unterschiedliche Vorstellungen von den Anforderungen, unerwartete Risiken, nicht eingehaltene Fristen... Viele IT-Projekte scheitern schon vor dem Go-Live. Auch bei den abgeschlossenen Projekten werden häufig die Ziele nicht erreicht. Beispiele wie Toll-Collect oder das FISKUS Steuerverwaltungssystem mit Kostensteigerungen von mehr als 1.000 Prozent bilden nur die Spitze des Eisbergs.

Ein Blick auf solche und ähnliche Projektverläufe macht deutlich, welche Ansatzpunkte bei der Vertragsgestaltung und bei der Projektsteuerung bestehen. Denn bei IT-Projektverträgen besteht viel Gestaltungsfreiheit – soweit es sich um Individualvereinbarungen handelt. Damit lassen sich Möglichkeiten schaffen, dem Scheitern vorzubeugen. Im Folgenden zeige ich Gestaltungsmöglichkeiten aus der Praxis von IT-Projekten auf, die bei der Abnahme, der Projektbeendigung und beim Schadensersatz bestehen.

Abnahme

Wenn sich aus der Leistungsbeschreibung eine Verpflichtung zur Herstellung eines Erfolgs ergibt, wenden Gerichte die Werkvertragsklauseln nach §§ 631 ff. BGB an. Eine Abnahme gehört zu den wesentlichen Elementen eines solchen Werkvertragsrechts.

Der Anspruch auf Abnahme besteht erst dann, wenn das Werk frei von Mängeln ist. Das heißt, der Auftraggeber muss die Abnahme erst dann erklären, wenn es dem vertraglich zugesagten Erfolg voll und ganz entspricht. Bei einer Softwareanwendung bedeutet dies, dass der Auftraggeber als Voraussetzung für die Erklärung der Abnahme zunächst verlangen kann, dass die vereinbarten Funktionalitäten vollständig geliefert wurden. Darüber hinaus müssen die abzubildenden Geschäftsprozesse mit der Anwendung vollständig und im Wesentlichen fehlerfrei abgebildet werden können. In der praktischen Umsetzung bereitet nicht nur die vertragliche Gestaltung der Abnahmevoraussetzungen Schwierigkeiten, sondern auch die Durchführung der Abnahmeprüfungen.

  • Abnahmekriterien: Auch wenn sich in der Literatur alle nahezu einig sind, dass es in jedem Vertrag eine vollständige und konsistente Leistungsbeschreibung braucht, wird dieses Kernstück eines IT-Projektvertrags häufig vernachlässigt. Die Bearbeitung der Anforderungsdokumente liegt oft beim Vertrieb, ohne dass Entwicklungsabteilung und Projektmanagement einbezogen werden. So sind Leistungsbeschreibungen häufig unvollständig und zu wenig konkret (siehe dazu meinen Artikel „Worauf Unternehmen bei der Leistungsbeschreibung achten müssen“).

  • Tests und Abnahmeprüfungen: Ein Testkonzept oder Testleitfaden beschreibt für das konkrete IT-Projekt die vorgegebenen Mindestanforderungen an die Testvorgehensweise, die Zuständigkeiten, der Verantwortlichkeiten und Abhängigkeiten. Weiterhin werden im Testkonzept die Rahmenbedingungen (z.B. Testumgebung), Ziele des Testvorgehens, die zu verwendenden Testmethoden und Testverfahren sowie der Umfang der durchzuführenden Tests festgelegt.

  • Beurteilung einer erfolgreichen Abnahme: Vertragliche Regelungen stellen nahezu ausschließlich auf die maximale Anzahl Mängel ab. Theoretisch ist die Vertragsgemäßheit dann gegeben, wenn sämtliche Anforderungen des Auftraggebers umgesetzt wurden. Die Überprüfung, ob dies tatsächlich der Fall ist, wird aber in der Regel dadurch erschwert, dass die Anforderungen gerade nicht über den erforderlichen Detaillierungsgrad verfügen. Eine Abnahme unter dem Vorbehalt der Beseitigung bestimmter Mängel dürfte dann der wirtschaftlichere Weg sein als die Verweigerung der Abnahme wegen einer Überschreitung der Anzahl Mängel in einer bestimmten Kategorie. Anders sieht die Lage dann aus, wenn der Auftraggeber mit dem Projektstatus ohnehin unzufrieden ist und Gründe für die Verweigerung der Abnahme sucht. Als Anbieter hat man an diesem Punkt meist schlechte Karten. Es stellt sich die Frage, ob als Voraussetzungen für die Abnahme nicht andere oder zumindest zusätzliche Kriterien festgelegt werden können. Neben der Mängelanzahl könnte etwa zusätzlich darauf abgestellt werden, wie hoch die Anzahl erfolgreich abgeschlossenen Testfälle ist.

  • Gestaltungshinweise: Die Durchführung des Go-Live hängt nicht nur davon ab, dass die Abnahmeprüfung erfolgreich durchgeführt werden kann, sondern auch davon, dass die Vorstufen absolviert werden konnten. Damit festgestellt werden kann, ob die Abnahmeprüfung überhaupt begonnen werden muss, sollten die vertraglichen Regelungen auch (quantitative und qualitative) Kriterien für den Eintritt in die Abnahmeprüfung umfassen. Ein gescheitertes IT-Projekt ist auch für den Auftraggeber meist ein wirtschaftliches Desaster, selbst dann, wenn er seine Sekundäransprüche detailliert geregelt hat. Vertragliche Vereinbarungen zur Abnahme sollten die Bereitschaft zur Durchführung und zum Abschluss einer Abnahmeprüfung fördern und nicht so unflexibel sein, dass sie den erfolgreichen Abschluss eines Projekts verhindern.

Projektbeendigung

  • Rücktritt: Für den Anbieter ist der Rücktritt und die daraus folgende Rückabwicklung das Worst Case-Szenario. Soweit der Projektvertrag keine anderweitige Regelung trifft, gelten hierfür die allgemeinen gesetzlichen Bestimmungen. Der Anbieter muss im Falle des berechtigten Rücktritts die bereits erhaltene Vergütung zurückerstatten und ist – sofern ihm eine schuldhafte Pflichtverletzung nachweisbar ist – noch schadensersatzpflichtig. Die Schadensersatzverpflichtung ist nach den gesetzlichen Bestimmungen der Höhe nach unbegrenzt, es sei denn die Vertragspartner treffen eine hiervon abweichende individualvertragliche Haftungsbegrenzung. Je nach Projektvolumen können existenzbedrohende Zahlungen auf einen Anbieter zu kommen. Ihm wird daran gelegen sein, bei der Vertragsgestaltung möglichst hohe Hürden für den Rücktritt zu schaffen.

  • Ordentliche Kündigung: Falls ein IT-Projekt scheitert, wird der Auftraggeber die Kündigung nach § 649 BGB gerade nicht in Erwägung ziehen, da er dem Anbieter im Regelfall keine (weitere) Vergütung bezahlen will. Sofern er sich dazu entscheidet ein IT-Projekt zu beenden, ist ihm in jedem Fall zu empfehlen, nicht einfach das Projekt zu stoppen, was als Kündigung im Sinne von § 649 BGB ausgelegt werden könnte, sondern seine Erklärungen so zu gestalten, dass sie entweder als Rücktritt oder als außerordentliche Kündigung zu werten sind.

  • Außerordentliche Kündigung: Die Kündigung aus wichtigem Grund setzt die Unzumutbarkeit der Vertragsfortführung für den Auftraggeber und ein Zurechnungsmoment, nicht notwendig ein Verschulden, auf Seiten des Anbieters voraus. Im Unterschied zum Rücktritt wird der Vertrag durch die Kündigung nur mit Wirkung für die Zukunft beendet. Dies bedeutet, dass die erbrachten Leistungen beim Auftraggeber verbleiben, dieser die erbrachten Leistungen allerdings auch vergüten muss. Eine solche Vergütungspflicht setzt freilich voraus, dass das erbrachte Werk mangelfrei ist. Der Auftraggeber kann einer solchen Vergütungspflicht auch entgegenhalten, die erbrachte Teilleistung sei für ihn völlig nutzlos.

Schadensersatz

Neben dem Rücktritt besteht im Falle eines gescheiterten IT-Projekts ein Anspruch auf Schadensersatz (§§ 281, 280 BGB). Der Auftraggeber muss dazu nachweisen, dass eine Vertragspflicht verletzt wurde. Eine Begrenzung der Schadenssumme, die dem Anbieter ausreichend Sicherheit bietet, ist in AGB nicht denkbar, da es im Regelfall nicht möglich sein dürfte, den vertragstypisch vorhersehbaren Schaden im Vorfeld zu bestimmen. Es bleibt nur der Weg des individuellen Aushandelns. Bei komplexen IT-Projekten ist es daher nicht ungewöhnlich, dass Haftungsklauseln in mehreren Versionen ausgetauscht werden und beide Vertragspartner ihre Vorstellungen zumindest teilweise einbringen können. Darüber hinaus versuchen immer mehr Auftraggeber, sich den Schadensnachweis durch die Vereinbarung von Pauschalierungen und Mindesthaftungssummen zu erleichtern. Denkbar ist es, jeden Projektmeilenstein mit einer bestimmten Mindesthaftungssumme zu verknüpfen, die unabhängig von der Vorlage eines konkreten Schadensnachweises zu zahlen ist.

Gestaltungsfreiheit nutzen

Gerade weil viele Projekte scheitern und damit für beide Seiten erhebliche finanzielle Risiken bergen, sollten Anbieter und Auftraggeber die Gestaltungsfreiheit bei IT-Auslagerungen nutzen. Wir beraten auslagernde Unternehmen und IT-Dienstleister bei der Vertragsgestaltung und helfen ihnen dabei, die Risiken zu identifizieren und wichtige Punkte zu regeln. Außerdem unterstützen wir Sie bei konkreten Fragen zum Umsetzen des Outsourcings. Ich freue mich über Ihre Anmerkungen und Kommentare!

Michaela Witzel, LL.M. Fordham University, School of Law, NYC, Fachanwältin für IT-Recht
witzel@web-partner.de