Anatomie von IT-Desastern: Wie Sie die 7 häufigsten Streitpunkte in IT-Projekten vermeiden

Jedes große IT-Projekt beginnt mit einer Vision: Effizientere Prozesse, neue Geschäftsmodelle, ein entscheidender Wettbewerbsvorteil. Doch die Realität sieht oft anders aus. Die Statistik ist ernüchternd: Laut Experten scheitern rund 20 % aller IT-Projekte komplett, und weniger als die Hälfte wird wirklich erfolgreich abgeschlossen. Die meisten enden mit Verzögerungen, explodierenden Kosten oder einem enttäuschenden Leistungsumfang.

Wenn ein IT-Projekt scheitert, beginnt die juristische Aufarbeitung – ein oft zermürbender und teurer Prozess, der nicht selten vor Gericht oder in einem Schiedsverfahren endet. Die Fronten sind verhärtet, die Schuldzuweisungen endlos, und die ursprüngliche Partnerschaft liegt in Trümmern.

Ich zeigen Ihnen die sieben kritischsten juristischen Schlachtfelder und gebe Tipps, um diese Konflikte zu vermeiden oder im Ernstfall für sich zu entscheiden

Streitpunkt 1: Das gebrochene Versprechen – Die Tücken der vorvertraglichen Beratung

Das Szenario: Das Projekt ist gescheitert. Der Kunde ist überzeugt, dass die ihm verkaufte Standardsoftware für seine Zwecke von Anfang an ungeeignet war. Er kann vielleicht keine konkreten Softwarefehler benennen, aber das Gesamtergebnis ist eine Katastrophe.

• Der Kunde argumentiert: „Sie als Experte hätten erkennen und uns sagen müssen, dass Ihre Software unsere Kernprozesse gar nicht abbilden kann! Sie haben uns falsch beraten.“

• Der Anbieter kontert: „Wir sind kein Unternehmensberater. Sie haben die Software gekauft, die Sie bestellt haben. Für Ihre Geschäftsprozesse sind Sie selbst verantwortlich.“

Die rechtliche Realität: Hier geht es um die Verletzung vorvertraglicher Beratungs- und Informationspflichten. Es ist ein weit verbreiteter Irrtum, dass ein Softwareanbieter immer eine umfassende Beratung schuldet. Dem Gesetz ist eine generelle Beratungspflicht fremd. Ob eine solche Pflicht im Einzelfall bestand, muss das Gericht klären.

Entscheidende Faktoren sind:

• Hatte der Anbieter ein klares Informationsgefälle und erkennbar größeren Sachverstand?

• Hat der Anbieter den Eindruck erweckt, eine umfassende Analyse und Beratung durchzuführen?

• Hatte der Kunde seine Ziele und Anforderungen klar kommuniziert, sodass der Anbieter die mangelnde Eignung hätte erkennen müssen?

Praxis-Tipp: Erwartungsmanagement ist alles!

• Für Anbieter: Dokumentieren Sie im Angebot präzise, auf welchen Informationen und Annahmen Ihre Lösung basiert. Halten Sie fest, welche Kundenanforderungen die Software erfüllt und welche nicht. Vermeiden Sie vollmundige Werbeversprechen, die eine Allzwecklösung suggerieren.

• Für Kunden: Formulieren Sie Ihre Ziele und wichtigsten Anforderungen so konkret wie möglich schriftlich und machen Sie sie zur Vertragsgrundlage. Fragen Sie explizit nach, ob die Software bestimmte, für Sie kritische Funktionen abdeckt.

Streitpunkt 2: Der Streit um den Leistungsumfang (Scope)

Dies ist der absolute Klassiker und die Mutter vieler IT-Konflikte. Was genau hat der Anbieter geschuldet? Hier entzünden sich die teuersten Auseinandersetzungen, meist in zwei Varianten:

a) Scope Creep: Der Versuch, mehr Leistung für das gleiche Geld zu bekommen

• Der Kunde argumentiert: „Diese Funktion ist für unsere Branche absolut zwingend notwendig. Es ist doch selbstverständlich, dass sie Teil des Projekts sein muss, auch wenn sie nicht explizit im Vertrag steht!“

• Der Anbieter kontert: „Diese Funktion steht nicht in der Leistungsbeschreibung. Das ist eine nachträgliche Erweiterung, die wir gerne umsetzen – aber nur gegen zusätzliche Vergütung.“

Die rechtliche Realität: Ohne eine präzise, detaillierte und als Vertragsbestandteil vereinbarte Leistungsbeschreibung ist die Position des Anbieters schwach. Bei Standardsoftware kann er sich meist auf die offizielle Produktbeschreibung berufen. Bei Individualsoftware oder branchenspezifischen Anpassungen wird es schwierig. Gerichte könnten argumentieren, dass bestimmte branchenübliche Standards stillschweigend mitgeschuldet sind.

b) Mangel vs. Change Request: Der teure Unterschied

Dies ist die Kehrseite des Scope Creep und ein noch häufigerer Streitpunkt.

• Der Kunde meldet: „Die Software kann keine X-Berichte erstellen. Das ist ein klarer Mangel! Bitte beheben Sie das kostenlos im Rahmen der Gewährleistung.“

• Der Anbieter antwortet: „Die Erstellung von X-Berichten war nie Teil des vereinbarten Leistungsumfangs. Ihr Wunsch ist ein ‚Change Request‘. Wir erstellen Ihnen gerne ein Angebot für die Umsetzung.“

Die rechtliche Realität: Die Antwort liegt allein im Vertrag und seiner Leistungsbeschreibung. Jede Unklarheit geht zu Lasten der Partei, die die Beweislast trägt. Dahinter kann auch eine bewusste Strategie des Anbieters stecken: In der Akquise wird ein sehr niedriger Preis angeboten, um den Auftrag zu gewinnen, wohl wissend, dass später über zahlreiche, teure Change Requests die eigentliche Marge erzielt wird.

Praxis-Tipp: Meißeln Sie den Scope in Stein! Die Ursache dieser Konflikte ist fast immer ein mangelhaftes Anforderungsmanagement. Vermeiden Sie diesen Streit durch:

• Lastenheft (Sache des Kunden): Der Kunde beschreibt detailliert, was die Software können muss (Ziele, Anforderungen, Prozesse).

• Pflichtenheft (Sache des Anbieters): Der Anbieter beschreibt, wie er die Anforderungen aus dem Lastenheft technisch umsetzen wird.

• Workshops? Nur mit Protokoll! Die beliebte Methode, Anforderungen in Workshops zu klären, ist extrem gefährlich, wenn die Ergebnisse nicht lückenlos und von beiden Seiten bestätigt dokumentiert werden. Ohne Dokumentation ist ein späterer Beweis im Prozess fast unmöglich.

Streitpunkt 3: Verzug und die Schuldfrage

Kaum ein IT-Projekt wird pünktlich fertig. Der Streit um die Verzögerung ist vorprogrammiert.

• Der Kunde wirft vor: „Sie sind seit Wochen im Verzug! Wir setzen Ihnen eine letzte Frist, ansonsten treten wir vom Vertrag zurück und fordern Schadensersatz.“

• Der Anbieter verteidigt sich: „Wir konnten nicht weiterarbeiten, weil Sie uns die notwendigen Informationen nicht geliefert und Entscheidungen nicht getroffen haben. Der Verzug liegt allein in Ihrer Verantwortung!“

Die rechtliche Realität: Dieser Konflikt dreht sich fast immer um die Mitwirkungspflichten des Kunden. Viele Kunden unterschätzen massiv den eigenen Aufwand, der für ein IT-Projekt notwendig ist (Daten bereitstellen, Prozesse beschreiben, Entscheidungen treffen, Tests durchführen).

Entscheidend ist:

• Sind die Mitwirkungspflichten im Vertrag klar definiert? Oft sind sie nur vage beschrieben oder fehlen ganz.

• Hat der Anbieter den Kunden klar und nachweisbar zur Mitwirkung aufgefordert? Mündliche Bitten in Workshops sind im Prozess wertlos.

• Wurden die Voraussetzungen für die Leistungserbringung klar definiert (sog. „Annahmen und Abhängigkeiten“)?

Praxis-Tipp: Dokumentieren Sie jede Interaktion!

• Für Anbieter: Jede Anfrage an den Kunden, jede ausstehende Entscheidung, jede Verzögerung durch den Kunden muss schriftlich (E-Mail genügt) und mit Fristsetzung dokumentiert werden. Erstellen Sie eine „Offene-Punkte-Liste“ und eskalieren Sie, wenn keine Reaktion erfolgt.

• Für Kunden: Nehmen Sie Ihre Mitwirkungspflichten ernst und planen Sie die notwendigen internen Ressourcen ein. Wenn Sie vom Anbieter Informationen benötigen, um mitwirken zu können, fordern Sie diese ebenfalls schriftlich an.

Streitpunkt 4: Der Moment der Wahrheit – Die verweigerte Abnahme

Die Software ist fertiggestellt (sagt der Anbieter), aber der Kunde weigert sich, die Abnahme zu erklären.

• Der Anbieter fordert: „Die Software ist abnahmereif. Bitte erklären Sie die Abnahme, damit wir die Schlussrechnung stellen können.“

• Der Kunde erwidert: „Niemals! Die Software ist voller Fehler und funktioniert nicht wie vereinbart. Wir verweigern die Abnahme.“

Die rechtliche Realität: Die Abnahme ist ein entscheidender Wendepunkt im Projekt. Mit der Abnahme kehrt sich die Beweislast um: Vorher muss der Anbieter beweisen, dass die Software mangelfrei ist. Nachher muss der Kunde beweisen, dass ein Mangel vorliegt.

Die größten Fallstricke:

• Fehlendes Abnahmeverfahren: Oft ist im Vertrag nicht geregelt, wie die Abnahme getestet wird, wer Testfälle und Testdaten liefert und was genau „abnahmereif“ bedeutet.

• Die Abnahmefiktion: Viele Anbieterverträge enthalten Klauseln, wonach die Software als abgenommen gilt, wenn der Kunde sie produktiv nutzt oder nicht innerhalb einer bestimmten Frist Mängel rügt. Diese Falle schnappt häufig zu!

Praxis-Tipp: Definieren Sie die Spielregeln der Abnahme im Voraus!

• Vereinbaren Sie ein klares Abnahmeverfahren mit definierten Testfällen und Kriterien für eine erfolgreiche Abnahme.

• Kunden müssen auf Abnahmefiktionsklauseln achten und bei Mängeln fristgerecht und schriftlich die Abnahme unter Angabe der Gründe verweigern.

Streitpunkt 5: Die Retourkutsche, aka Widerklage

Nach meiner Erfahrung gibt es in sehr vielen Prozessen über ein gescheitertes IT-Projekt eine Widerklage.

• Szenario 1: Der Kunde klagt auf Rückzahlung der geleisteten Vergütung und Schadensersatz. Der Anbieter erhebt Widerklage auf Zahlung seiner noch offenen Rechnungen.

• Szenario 2: Der Anbieter klagt auf Zahlung seiner offenen Rechnungen. Der Kunde erhebt Widerklage auf Rückzahlung und Schadensersatz.

Die rechtliche Realität: Es erscheint mir oft reiner Zufall, wer zuerst klagt. Die Gegenseite wird fast immer mit eigenen Forderungen nachziehen.

Praxis-Tipp: Kalkulieren Sie das volle Risiko! Bei der Prüfung des Prozessrisikos und der Kosten muss die sehr hohe Wahrscheinlichkeit einer Widerklage von Anfang an berücksichtigt werden. Dies verdoppelt schnell den Streitwert und damit die Anwalts- und Gerichtskosten.

Streitpunkt 6: SCRUM – Wenn die Projektmethode zum Rechtsstreit wird

Agile Methoden wie Scrum sind beliebt, führen im Streitfall aber zu fundamentalen rechtlichen Problemen.

• Der Anbieter argumentiert (oft): „Wir haben agil gearbeitet. Das ist ein Dienstvertrag. Wir schulden nur unser bestes Bemühen, keinen fertigen Erfolg. Sie müssen unsere Stunden bezahlen.“

• Der Kunde argumentiert: „Mir egal, wie Sie es nennen. Ich wollte eine funktionierende Software. Das ist ein Werkvertrag. Sie haben den Erfolg nicht geliefert, also bezahle ich nicht.“

Die rechtliche Realität: Die Gerichte sind sich uneins. Ob ein agiler Vertrag als Dienst- oder Werkvertrag einzuordnen ist, hängt vom Einzelfall und der genauen Vertragsgestaltung ab. Oft tragen Verträge die Überschrift „Werkvertrag“, enthalten aber nur dienstvertragliche Regelungen (oder umgekehrt). Eine dynamische Leistungsbeschreibung im „Product Backlog“ und die Abnahme von „Softwareinkrementen“ am Ende von Sprints machen die Sache noch komplexer.

Praxis-Tipp: Schaffen Sie vertragliche Klarheit! Verlassen Sie sich nicht auf die Bezeichnung der Projektmethode. Der Vertrag muss unmissverständlich regeln, ob ein konkreter Erfolg geschuldet wird (Werkvertrag) oder nur ein Tätigwerden (Dienstvertrag). Regeln Sie, was am Ende eines Sprints passiert – ist die Lieferung eines Inkrements eine verbindliche Teilabnahme?

Streitpunkt 7: Wer hat Recht? Wer kann es beweisen? Die entscheidende Rolle der Dokumentation

Am Ende eines jeden Streits steht die Frage der Beweislast. Wer seine Behauptungen nicht beweisen kann, verliert den Prozess, selbst wenn er im Recht ist.

Die größten Herausforderungen:

• Darlegung von Mängeln: Ein Kunde muss die Mängel nicht technisch präzise beschreiben. Es genügt, die Symptome darzulegen („Wenn ich auf Button X klicke, stürzt das Programm ab“). Dennoch wird hierüber oft erbittert gestritten.

• Beweis der Mitwirkung: Die Partei, die sich darauf beruft, dass die andere ihre Mitwirkungspflichten verletzt hat, muss dies beweisen. Pauschale Behauptungen reichen nicht.

• Die digitale Dokumentations-Falle: Projekte werden heute in Online-Tools wie JIRA, Confluence oder Slack dokumentiert. Meist hat nur eine Partei (oft der Anbieter) die Hoheit über diese Tools. Im Streitfall wird der Zugang für die Gegenseite einfach gesperrt.

Die Konsequenz: Eine Partei sitzt auf dem gesamten Beweismaterial, während die andere mit leeren Händen dasteht. Im deutschen Zivilprozess mit seinem Beibringungsgrundsatz ist dies ein massiver Nachteil, der kaum zu heilen ist.

Praxis-Tipp: Sichern Sie Ihre Beweise – von Tag 1 an! Bestehen Sie vertraglich auf einem permanenten, eigenen Zugang zu allen Projekt-Dokumentationstools. Noch besser: Sorgen Sie für regelmäßige, automatische Exporte der gesamten Projektdokumentation auf Ihre eigenen Systeme. Diese Vorsichtsmaßnahme kann im Streitfall über Sieg oder Niederlage entscheiden.

Fazit: Prävention ist die beste Litigation-Strategie

Gescheiterte IT-Projekte sind selten Schicksalsschläge. Sie sind fast immer das Resultat von unklaren Vereinbarungen, mangelhafter Kommunikation und fehlender Dokumentation – vorhersehbare Fehler, die vermeidbar sind.

Ein präziser, fair ausgehandelter und gut dokumentierter Vertrag ist keine bürokratische Hürde, sondern die beste Versicherung gegen teure Auseinandersetzungen. Er ist das Fundament für eine erfolgreiche Partnerschaft und Ihr stärkstes Schwert, wenn die Dinge doch einmal schieflaufen.