Mängelmanagement im IT-Projekt: Fehler dokumentieren und Ansprüche sichern

Mängel gehören zum Alltag komplexer IT-Projekte. Entscheidend ist nicht allein, ob Software fehlerfrei geliefert wird, sondern wie Beanstandungen festgestellt, dokumentiert, rechtlich eingeordnet und gegenüber dem Vertragspartner geltend gemacht werden. Eine unklare Mängelrüge, eine vorschnelle Abnahme oder eine unzureichende Dokumentation können dazu führen, dass berechtigte Ansprüche später nur schwer durchsetzbar sind.

Ein strukturiertes Mängelmanagement schafft deshalb die Grundlage für eine geordnete Nacherfüllung, eine belastbare Beweislage und – falls erforderlich – die weitere rechtliche Eskalation.

Welche Mängelrechte bestehen?

Welche Rechte bei fehlerhaften IT-Leistungen bestehen, hängt zunächst vom zugrunde liegenden Vertragstyp ab. Beim Werkvertrag stehen dem Auftraggeber insbesondere Nacherfüllung, Minderung, Rücktritt und Schadensersatz nach §§ 633 ff. BGB zur Verfügung. Bei einem reinen Dienstvertrag besteht dagegen kein vergleichbares werkvertragliches Gewährleistungsrecht.

Entscheidend ist daher, ob der Auftragnehmer einen konkret definierten Erfolg oder lediglich eine Tätigkeit schuldet. Für das Mängelmanagement muss diese Einordnung geklärt sein, bevor Ansprüche geltend gemacht und Fristen zur Nacherfüllung gesetzt werden.

Welche Bedeutung die Abnahme für Mängelansprüche hat

Im Werkvertragsrecht ist die Abnahme der zentrale Zeitpunkt: Sie löst die Fälligkeit der Vergütung aus, kehrt die Beweislast zu Lasten des Auftraggebers um und setzt die Verjährung von Mängelansprüchen in Gang (§ 640 BGB, § 634a Abs. 2 BGB).

Der BGH definiert Abnahme als körperliche Entgegennahme des Werks verbunden mit dessen Billigung als im Wesentlichen vertragsgerecht (BGH, Urt. v. 25.03.1993 – X ZR 17/92). Diese Billigung darf nicht vorschnell unterstellt werden: In seiner Entscheidung vom 05.06.2014 (VII ZR 276/13) hat der BGH klargestellt, dass eine bloße Übernahmebestätigung keine Abnahme darstellt, wenn dem Auftragnehmer bekannt war, dass die Software zu diesem Zeitpunkt noch nicht vollständig funktionsfähig war. Für Auftraggeber folgt daraus: keine vorbehaltlosen Erklärungen vor vollständigem Funktionstest. Für Auftragnehmer: eine förmliche, dokumentierte Abnahme schafft Rechtssicherheit auf beiden Seiten.

Darlegungs- und Beweislast bei Softwaremängeln

Häufig streiten die Parteien darüber, wie detailliert ein Mangel vorgetragen werden muss. Der BGH hat die Anforderungen in der Entscheidung VII ZR 276/13 zugunsten des Bestellers präzisiert: Es genügt, die Mangelerscheinung – das, was nicht funktioniert – genau zu bezeichnen. Zur technischen Ursache muss nicht vorgetragen werden; sie ist Gegenstand des Beweises, nicht des Sachvortrags.

Praktisch heißt das: Auftraggeber sollten Mängel konkret, aber ohne Ursachenanalyse rügen – etwa durch Protokollierung, welche vereinbarte Funktion in welcher Situation versagt. Auftragnehmer sollten sich nicht darauf verlassen, dass unpräzise Rügen automatisch unbeachtlich bleiben.

So sollte eine Mängelrüge im IT-PRpjekt dokumentiert werden

Eine Mängelrüge sollte die konkrete Funktionsabweichung so dokumentieren, dass sie auch zu einem späteren Zeitpunkt nachvollzogen und reproduziert werden kann. Eine pauschale Aussage wie ‚die Software funktioniert nicht‘ reicht für ein professionelles Mängelmanagement nicht aus.

Dokumentiert werden sollten insbesondere die betroffene Funktion oder der Prozessschritt, das vereinbarte beziehungsweise erwartete Verhalten, das tatsächlich beobachtete Verhalten, die verwendete Testumgebung und Testdaten sowie vorhandene Fehlermeldungen, Screenshots oder Protokolle. Sinnvoll ist außerdem festzuhalten, ob der Fehler reproduzierbar ist und welche Nutzer oder Geschäftsprozesse betroffen sind.

Die technische Ursache des Fehlers muss der Auftraggeber dagegen nicht abschließend bestimmen. Entscheidend ist zunächst die konkrete und nachvollziehbare Beschreibung der Mangelerscheinung.

Fehlerklassifizierung als Steuerungsinstrument

Nicht jeder Mangel wiegt gleich schwer. Bewährt hat sich die vertragliche Einteilung in Fehlerklassen – von schwerwiegenden Fehlern, die die Nutzung wesentlicher Funktionen ausschließen, bis zu geringfügigen Abweichungen ohne relevante Betriebsbeeinträchtigung. Klar definierte Fehlerklassen erleichtern die Priorisierung der Nacherfüllung, verknüpfen Reaktions- und Behebungsfristen mit der Schwere des Fehlers und schaffen einen objektiven Maßstab dafür, wann ein Projekt als abnahmereif gilt. Fehlt eine solche Regelung, führt bereits die Frage, ob ein Fehler die Abnahme hindert, regelmäßig zum Streit. Die Fehlerklassen sollten deshalb nicht nur beschrieben, sondern mit konkreten Folgen verbunden werden: Welche Fehler verhindern die Abnahme oder den Go-live? Welche Reaktions- und Behebungsfristen gelten? Wann genügt ein Workaround und wann muss vollständig nachgebessert werden?

Mitwirkungspflichten des Auftraggebers

Mängelmanagement betrifft nicht allein den Dienstleister. IT-Projekte gelingen nur bei funktionierender Zusammenarbeit: Bereitstellung von Testdaten, Zugängen und Ansprechpartnern, rechtzeitige Rückmeldungen, geordnetes Change-Management. Verletzt der Auftraggeber solche Mitwirkungspflichten oder verzögern häufige Änderungswünsche den Ablauf, kann dies die Verantwortung für Verzögerungen und Fehler verschieben. Beide Seiten sollten Mitwirkungshandlungen, Change-Requests und deren Auswirkungen auf Termin und Budget daher konsequent dokumentieren.

Verjährung nicht unterschätzen

Mängelansprüche aus Werkverträgen verjähren nach § 634a BGB regelmäßig in zwei Jahren ab Abnahme, wenn die Werkleistung eine körperliche Sache betrifft oder bearbeitet; bei rein individuell programmierter Software wird teils die dreijährige Regelverjährung diskutiert.

Das OLG Hamm (Urt. v. 26.02.2014 – 12 U 112/13) hat für die Lieferung, Installation und individuelle Anpassung von Standardsoftware samt Hardware die zweijährige Frist des § 634a Abs. 1 Nr. 1 BGB angewendet und die dreijährige Auffangfrist abgelehnt, weil die Werkleistung nicht überwiegend immateriell geprägt war. Zugleich stellte das Gericht klar, dass auch eine endgültige – selbst berechtigte – Abnahmeverweigerung die Verjährung in Gang setzt. Wer die Abnahme dauerhaft verweigert, muss seine Ansprüche also fristgerecht geltend machen, statt sich allein auf offene Mängel zu berufen.

Praktische Konsequenzen für beide Vertragsseiten

Für Auftraggeber:

• Leistungsbeschreibung, Abnahmekriterien und Fehlerklassen vor Vertragsschluss konkret fassen.
• Abnahme erst nach vollständigem, dokumentiertem Funktionstest erklären.
• Mängel zeitnah, konkret und schriftlich rügen; Fristen zur Nacherfüllung setzen.
• Mitwirkungshandlungen und Änderungswünsche dokumentieren.
• Verjährungsfristen im Blick behalten, gerade bei laufenden Nachbesserungen.

Für Auftragnehmer:

• Auf förmliche, protokollierte Abnahme hinwirken statt auf stillschweigende Duldung zu vertrauen.
• Mängelrügen dokumentiert bearbeiten, auch bei zunächst unvollständigem Sachvortrag.
• Change-Requests klar von ursprünglich vereinbarten Leistungen abgrenzen.
• Verletzte Mitwirkungspflichten des Auftraggebers rechtzeitig und nachweisbar kommunizieren.
• Eigene Fristenkontrolle für Gewährleistung und Verjährung etablieren.

Rechtliche Begleitung zahlt sich aus

Mängelmanagement in IT-Projekten ist kein rein technisches Thema. Eine belastbare Leistungsbeschreibung, definierte Abnahmekriterien, nachvollziehbare Fehlerklassifizierung und eine saubere Dokumentation entscheiden darüber, ob Ansprüche später tatsächlich durchsetzbar sind.

Wir unterstützen Auftraggeber und IT-Dienstleister dabei, Mängel rechtlich einzuordnen, Mängelrügen und Nacherfüllungsprozesse zu strukturieren und Ansprüche durchzusetzen oder abzuwehren.

Ist das Projekt bereits so weit eskaliert, dass eine Fortführung nicht mehr sinnvoll erscheint, müssen zusätzlich die Voraussetzungen und wirtschaftlichen Folgen einer Kündigung im IT-Projekt geprüft werden.

Erfahren Sie mehr über unsere weiteren Leistungen