In IT-Vertragsstreitigkeiten dreht sich fast alles um eine Frage: Was war geschuldet – und was wurde geliefert? Die Antwort liegt in zwei Dokumenten, die in der Praxis erstaunlich oft fehlen, unvollständig sind oder widersprüchlich zueinander stehen: dem Lastenheft und dem Pflichtenheft. Für den IT-Sachverständigen sind sie der Ausgangspunkt jeder Begutachtung. Für die Parteien entscheiden sie häufig über den Ausgang des Verfahrens.
Was ist ein Lastenheft, was ein Pflichtenheft?
Die Unterscheidung klingt einfach, wird in der Praxis aber regelmäßig verwischt. Das Lastenheft beschreibt das „Was“ und „Wofür“: Es enthält die Anforderungen des Auftraggebers an die zu liefernde IT-Lösung. Welche Geschäftsprozesse soll die Software abbilden? Welche Funktionen werden benötigt? Welche Schnittstellen zu bestehenden Systemen müssen funktionieren? Das Lastenheft wird vom Auftraggeber erstellt und dokumentiert seine Erwartungen aus Anwendersicht, idealerweise lösungsneutral.
Das Pflichtenheft beschreibt das „Wie“ und „Womit“: Es ist die Antwort des IT-Dienstleisters auf das Lastenheft. Hier dokumentiert der Auftragnehmer, mit welchen konkreten Mitteln, Modulen und technischen Lösungen er die Anforderungen aus dem Lastenheft umsetzen will. Das Pflichtenheft wird vom Auftragnehmer erstellt, in der Regel in enger Abstimmung mit dem Auftraggeber. Nach der Freigabe durch den Auftraggeber wird es zum Vertragsbestandteil.
Gemäß DIN 69901-5 enthält das Lastenheft die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers“, das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes“. In Österreich hat die DIN-Norm keine unmittelbare Rechtswirkung, sie wird aber als anerkannter Standard in der IT-Branche herangezogen und spiegelt die saubere Trennung wider, die für die rechtliche Beurteilung entscheidend ist.
Warum die Unterscheidung für Vertragsstreitigkeiten so wichtig ist
In einem IT-Vertragsstreit muss das Gericht feststellen, ob die gelieferte Leistung mangelhaft ist. Dafür braucht es einen Maßstab: Was genau war die vereinbarte Beschaffenheit der Software? Diese Frage lässt sich nur beantworten, wenn klar ist, welche Dokumente Vertragsbestandteil geworden sind und welchen Inhalt sie haben.
Hier liegt das zentrale Problem: In vielen IT-Projekten werden Lastenheft und Pflichtenheft nicht sauber getrennt. Manchmal existiert nur ein einziges Dokument, das als „Spezifikation“ oder „Fachkonzept“ bezeichnet wird, ohne dass klar ist, ob es die Anforderungen des Auftraggebers oder die Umsetzungszusagen des Auftragnehmers enthält. Manchmal gibt es ein Lastenheft, aber kein formelles Pflichtenheft. Manchmal wurden beide Dokumente erstellt, aber das Pflichtenheft weicht inhaltlich vom Lastenheft ab, ohne dass diese Abweichungen formell vereinbart wurden.
Für den IT-Sachverständigen beginnt die Arbeit deshalb nicht mit einer technischen Prüfung, sondern mit einer Dokumentenanalyse: Welche Dokumente existieren? Welche wurden Vertragsbestandteil? Welchen Inhalt haben sie? Und wo widersprechen sie einander?
Die sieben typischen Problemfelder
In meiner Praxis als IT-Sachverständiger begegnen mir bei Vertragsstreitigkeiten immer wieder dieselben Konstellationen, in denen Lastenheft und Pflichtenheft zum Streitgegenstand werden.
Das fehlende Lastenheft. Erstaunlich viele IT-Projekte starten ohne ein formelles Lastenheft. Der Auftraggeber beschreibt seine Anforderungen mündlich, in E-Mails oder in einer Vertriebspräsentation des Anbieters. Wenn das Projekt scheitert, fehlt die dokumentierte Grundlage dafür, was der Auftraggeber tatsächlich gefordert hat. Als Sachverständiger muss ich dann aus der gesamten Projektkorrespondenz rekonstruieren, welche Anforderungen erkennbar waren. Das ist aufwändig und das Ergebnis ist zwangsläufig weniger belastbar als die Analyse eines sauber formulierten Lastenhefts.
Das zu vage Lastenheft. Manche Lastenhefte bestehen aus wenigen Seiten mit allgemeinen Formulierungen: „Das System soll die Auftragsabwicklung optimieren“ oder „Die Lösung muss die branchenüblichen Anforderungen erfüllen“. Solche Formulierungen sind für eine technische Begutachtung nahezu wertlos. Sie lassen keine prüfbare Soll-Ist-Abweichung feststellen, weil der Soll-Zustand nicht definiert ist. Der Sachverständige kann in solchen Fällen nur auf den Stand der Technik, die vorausgesetzte Verwendung gemäß § 922 ABGB und die gewöhnlich vorausgesetzten Eigenschaften abstellen.
Das fehlende Pflichtenheft. Wenn der IT-Dienstleister kein Pflichtenheft erstellt hat, fehlt die Dokumentation seiner konkreten Umsetzungszusagen. Das ist für den Auftragnehmer riskant, denn ohne Pflichtenheft schuldet er im Werkvertrag grundsätzlich ein Ergebnis, das den Anforderungen des Lastenhefts entspricht. Er kann sich nicht darauf berufen, dass er bestimmte Anforderungen anders interpretiert oder bewusst anders umgesetzt hat, wenn er diese Interpretation nicht dokumentiert hat.
Das Pflichtenheft als Verkaufsargument. In der ERP-Welt kommt es vor, dass das Pflichtenheft im Wesentlichen aus einer Funktionsliste des Standardsystems besteht, ergänzt um pauschale Zusagen wie „Anpassung an kundenspezifische Prozesse“. Solche Dokumente beschreiben das Produkt des Anbieters, nicht die Lösung für das konkrete Problem des Kunden. Als Sachverständiger prüfe ich, ob das Pflichtenheft tatsächlich eine individuelle Antwort auf das Lastenheft ist oder ob es sich um ein weitgehend standardisiertes Verkaufsdokument handelt.
Widersprüche zwischen Lastenheft und Pflichtenheft. Das Lastenheft fordert eine automatisierte Schnittstelle zum bestehenden Warenwirtschaftssystem, das Pflichtenheft sieht einen manuellen CSV-Import vor. Das Lastenheft verlangt die Abbildung branchenspezifischer Kalkulationslogik, das Pflichtenheft beschreibt eine Standardkalkulation mit „optionaler Anpassung“. Solche Widersprüche sind häufiger als man erwarten würde. Der Sachverständige muss feststellen, ob der Auftraggeber dem Pflichtenheft in Kenntnis dieser Abweichungen zugestimmt hat oder ob die Abweichung verdeckt war.
Nachträgliche Änderungen ohne Dokumentation. IT-Projekte entwickeln sich. Anforderungen ändern sich, neue kommen hinzu, andere werden gestrichen. Das ist normal und unvermeidlich. Problematisch wird es, wenn diese Änderungen nicht in einem formellen Change-Request-Verfahren dokumentiert werden. Dann stehen am Ende des Projekts ein ursprüngliches Pflichtenheft und eine gelieferte Software, die voneinander abweichen, ohne dass nachvollziehbar ist, welche Abweichungen vereinbart waren und welche Mängel darstellen.
Das agile Projekt ohne Spezifikation. Immer häufiger werden IT-Projekte nach agilen Methoden durchgeführt. Sprints, User Stories, Product Backlogs ersetzen das klassische Pflichtenheft. Das kann methodisch sinnvoll sein, schafft aber erhebliche Probleme, wenn es zum Streit kommt. Der Sachverständige muss aus Sprint-Protokollen, Story-Beschreibungen, Akzeptanzkriterien und Product-Backlog-Einträgen rekonstruieren, was zu welchem Zeitpunkt als Leistungsumfang vereinbart war. Die Dokumentationslage ist dabei häufig unübersichtlich und lückenhaft.
Was der IT-Sachverständige konkret prüft
Wenn ein Gericht oder eine Partei einen Sachverständigen mit der Begutachtung einer IT-Vertragsstreitigkeit beauftragt, geht die Prüfung systematisch in mehreren Schritten vor.
Im ersten Schritt wird der vertragliche Leistungsumfang ermittelt. Der Sachverständige analysiert den Vertrag, das Lastenheft, das Pflichtenheft und alle weiteren Dokumente, die Vertragsbestandteil geworden sind: Angebote, Beiblätter, Protokolle, Change Requests, E-Mail-Korrespondenz. Ziel ist eine vollständige Zusammenstellung dessen, was der Auftragnehmer schuldet. Dabei muss auch geklärt werden, welche Dokumente Vorrang haben, wenn sie sich widersprechen, also welche Rangfolge der Vertrag für seine Bestandteile vorsieht.
Im zweiten Schritt wird der Ist-Zustand der Software erfasst. Was leistet die gelieferte Software tatsächlich? Welche Funktionen sind vorhanden, welche fehlen, welche funktionieren nicht wie beschrieben? Diese Befundaufnahme ist technisch und erfordert Zugang zu den Systemen, Testdaten und gegebenenfalls zum Quellcode.
Im dritten Schritt erfolgt der Soll-Ist-Vergleich. Jede im Pflichtenheft dokumentierte Anforderung wird gegen den tatsächlichen Zustand der Software geprüft. Abweichungen werden kategorisiert: Ist die Funktion nicht vorhanden? Ist sie vorhanden, aber fehlerhaft? Ist sie vorhanden, funktioniert aber anders als spezifiziert? Jede dieser Kategorien hat unterschiedliche rechtliche Konsequenzen.
Im vierten Schritt werden die Ursachen der Abweichungen analysiert. Liegt ein Implementierungsfehler des Auftragnehmers vor? Oder war die Anforderung im Lastenheft so formuliert, dass eine andere Interpretation ebenfalls vertretbar war? Hat der Auftraggeber während des Projekts widersprüchliche Vorgaben gemacht? Hat er notwendige Informationen nicht bereitgestellt? Diese Ursachenanalyse ist entscheidend für die Zuordnung der Verantwortung.
Worauf Auftraggeber und Auftragnehmer achten sollten
Die meisten Streitigkeiten, die ich als Sachverständiger begutachte, hätten durch eine bessere Dokumentation vermieden oder zumindest entschärft werden können.
Für Auftraggeber gilt: Ein sorgfältig erstelltes Lastenheft ist die wichtigste Investition in die Absicherung Ihrer Ansprüche. Es sollte alle Anforderungen konkret, messbar und prüfbar formulieren. Allgemeine Formulierungen schaden ausschließlich dem Auftraggeber, weil sie keinen belastbaren Maßstab für die Prüfung der Leistung liefern. Und: Prüfen Sie das Pflichtenheft des Auftragnehmers sorgfältig, bevor Sie es freigeben. Was Sie freigeben, wird zum Vertragsbestandteil, auch wenn es vom Lastenheft abweicht.
Für Auftragnehmer gilt: Ein präzises Pflichtenheft schützt Sie vor Ansprüchen, die über das hinausgehen, was Sie zugesagt haben. Dokumentieren Sie klar, welche Anforderungen des Lastenhefts Sie wie umsetzen, und dokumentieren Sie ebenso klar, welche Anforderungen Sie nicht oder anders umsetzen. Die sogenannte negative Abgrenzung, also die explizite Auflistung dessen, was nicht Leistungsgegenstand ist, kann im Streitfall entscheidend sein.
Für beide Seiten gilt: Führen Sie ein formelles Change-Request-Verfahren. Jede Änderung gegenüber dem Pflichtenheft muss dokumentiert, von beiden Seiten freigegeben und gegebenenfalls mit einer Kosten- und Terminanpassung versehen werden. Mündliche Vereinbarungen oder beiläufige E-Mail-Zusagen sind im Streitfall kaum belastbar.
Wenn die Dokumentation fehlt: Was der Sachverständige trotzdem tun kann
Auch bei lückenhafter Dokumentation ist eine Begutachtung möglich, wenn auch aufwändiger. Der Sachverständige kann den vereinbarten Leistungsumfang aus der Gesamtheit der Projektdokumentation rekonstruieren: aus Angeboten, Protokollen, E-Mails, Statusberichten, Schulungsunterlagen, Testprotokollen und der Software selbst.
Darüber hinaus kann der Sachverständige auf objektive Maßstäbe zurückgreifen. Wenn keine konkrete Spezifikation existiert, schuldet der Auftragnehmer ein Werk, das sich für die gewöhnliche oder die nach dem Vertrag vorausgesetzte Verwendung eignet (§ 922 ABGB). Der Sachverständige kann dann beurteilen, ob die Software dem Stand der Technik entspricht, ob sie die branchenüblichen Anforderungen erfüllt und ob sie für den erkennbaren Verwendungszweck geeignet ist. Dieser Maßstab ist weniger präzise als ein konkretes Pflichtenheft, aber er bietet dem Gericht zumindest eine fachlich fundierte Grundlage.
Wann Sie einen Sachverständigen einschalten sollten
Ein IT-Sachverständiger kann in verschiedenen Phasen einer Vertragsstreitigkeit unterstützen. Vor der Einleitung eines Verfahrens liefert ein Privatgutachten eine realistische Einschätzung der technischen Sachlage und der Erfolgsaussichten. Im laufenden Verfahren beantwortet ein Gerichtsgutachten die Beweisfragen des Gerichts. Und auch außergerichtlich kann ein Sachverständiger als neutraler Dritter helfen, die technischen Streitpunkte zu klären und eine Grundlage für Vergleichsverhandlungen zu schaffen.
Wenn Sie in einer IT-Vertragsstreitigkeit stecken oder eine solche befürchten, stehe ich Ihnen als allgemein beeideter und gerichtlich zertifizierter IT-Sachverständiger für eine erste Einschätzung zur Verfügung. Im Erstgespräch kann ich beurteilen, ob die Dokumentationslage eine Begutachtung trägt und welche Fragen ein Gutachten beantworten kann. Kontaktieren Sie mich für ein unverbindliches Erstgespräch.