Ein Softwareprojekt, das nach sechs Monaten Entwicklungszeit weder abgenommen werden kann noch einen erkennbaren Leistungsumfang aufweist: Dieses Szenario ist in der Mandatspraxis häufiger, als viele Geschäftsführer erwarten. Die Frage, welcher Vertragstyp dem Projekt zugrunde liegt, entscheidet darüber, wer das Risiko trägt – und ob Nachbesserungsansprüche, Kündigung oder Schadensersatz überhaupt in Betracht kommen.
IT-Projektverträge für agile Softwareentwicklung bewegen sich im Spannungsfeld von Werkvertragsrecht (§§ 631 ff. BGB) und Dienstvertragsrecht (§§ 611 ff. BGB). Die Wahl des Vertragstyps bestimmt, ob der Auftraggeber einen abnahmefähigen Erfolg verlangen kann, welche Gewährleistungsfristen gelten und unter welchen Voraussetzungen ein Rücktritt oder Schadensersatz möglich ist. Für mittelständische Unternehmen, deren Geschäftsführer die Verantwortung für Budgettreue und Projekterfolg tragen, ist die vertragliche Weichenstellung vor Projektbeginn die entscheidende Risikominimierungsmaßnahme.
Dieser Beitrag erläutert den Rechtsrahmen für IT-Projektverträge, zeigt die vertragliche Einordnung agiler Methoden, benennt typische Fehlerquellen und gibt konkrete Handlungsempfehlungen für Auftraggeber im Mittelstand.
Warum der Vertragstyp über den Projekterfolg entscheidet
Ob ein IT-Projektvertrag als Werkvertrag oder als Dienstvertrag einzuordnen ist, hängt nicht von der Bezeichnung, sondern vom tatsächlich geschuldeten Inhalt ab. Das Bürgerliche Gesetzbuch unterscheidet: Der Werkvertrag (§ 631 BGB) verpflichtet zur Herbeiführung eines bestimmten Erfolgs; der Dienstvertrag (§ 611 BGB) schuldet lediglich das Tätigwerden.
Diese Unterscheidung hat weitreichende praktische Konsequenzen. Beim Werkvertrag stehen dem Auftraggeber im Fall von Mängeln die gesetzlichen Gewährleistungsrechte zu: Nacherfüllung, Selbstvornahme, Minderung, Rücktritt und Schadensersatz (§§ 634 ff. BGB). Die Verjährungsfrist für Mängelansprüche beträgt bei Bauwerken fünf Jahre (§ 634a Abs. 1 Nr. 2 BGB); für andere Werke, einschließlich typischer Softwarewerke, regelmäßig zwei Jahre ab Abnahme. Beim Dienstvertrag hingegen endet die Verpflichtung des Auftragnehmers mit dem Erbringen der vereinbarten Dienste – unabhängig vom Ergebnis.
In der Mandatspraxis sehen wir regelmäßig, dass Verträge für Softwareprojekte als „Rahmenverträge" oder „Entwicklungsdienstleistungen" bezeichnet werden, obwohl der wirtschaftliche Wille beider Seiten auf die Erstellung eines funktionierenden Systems gerichtet ist. Gerichte ordnen solche Verträge häufig als Werkverträge ein, wenn ein konkret beschriebener Leistungsumfang vereinbart und eine Abnahme vorgesehen ist. Der Auftragnehmer übernimmt damit das Fertigstellungsrisiko – ob er das kalkuliert hat, ist eine andere Frage.
Agile Methoden und ihr vertragliches Regelungsproblem
Agile Vorgehensmodelle wie Scrum oder Kanban sind nicht auf die klassische Vertragsarchitektur des BGB zugeschnitten. Sie zeichnen sich durch iterative Entwicklung in Sprints (typischerweise zwei bis vier Wochen), kontinuierliche Anforderungsanpassung und einen emergenten Leistungsumfang aus. Ein klassischer Pflichtenheft-Werkvertrag, der einen detaillierten Leistungsumfang vorab beschreibt, widerspricht diesem Ansatz strukturell.
Daraus entsteht ein rechtliches Grundproblem: Wenn kein abschließend definiertes Werk vereinbart ist, fehlt es an einem klaren Abnahmegegenstand. Ohne Abnahme beginnt die Gewährleistungsfrist nicht zu laufen, Schlusszahlungsansprüche sind nicht fällig, und die Haftungsverteilung bleibt unklar. Die fehlende oder unzureichend geregelte Abnahme ist nach unserer Erfahrung die häufigste Ursache für eskalierte IT-Streitigkeiten im Mittelstand.
Marktüblich haben sich drei Vertragsmodelle für agile Projekte herausgebildet:
- Reiner Dienstvertrag nach Aufwand (Time & Material): Der Auftragnehmer schuldet kein Ergebnis, sondern Arbeitszeit. Der Auftraggeber trägt das Fertigstellungsrisiko vollständig. Für den Mittelstand ungeeignet, wenn ein bestimmter Funktionsumfang wirtschaftlich zwingend erforderlich ist.
- Gemischter Vertrag mit Werkvertragselementen: Jeder Sprint oder jedes Release wird als eigenständiges Teilwerk mit definiertem Leistungsumfang und Teilabnahme ausgestaltet. Dieses Modell verbindet agile Flexibilität mit werkvertraglichem Gewährleistungsschutz und hat sich in der Praxis als belastungsfähigste Konstruktion bewährt.
- Rahmenvertrag mit Einzelabrufen: Ein übergeordneter Rahmenvertrag regelt die Grundbedingungen; einzelne Sprints oder Funktionspakete werden durch Einzelabrufe konkretisiert, die jeweils Werks- oder Dienstvertragscharakter haben können. Dieses Modell erfordert präzise Schnittstellen zwischen Rahmen- und Einzelvertrag.
Welche Klauseln in IT-Projektverträgen kritisch sind
Die vertragliche Gestaltung entscheidet, ob ein Streit am Verhandlungstisch oder vor Gericht endet. Nach unserer Erfahrung sind es regelmäßig dieselben Regelungslücken, die IT-Projekte in die Eskalation treiben.
Leistungsumfang und Änderungsmanagement (Change-Request-Verfahren): Agile Projekte leben von Anforderungsänderungen. Fehlt ein verbindliches Verfahren, nach dem Änderungen dokumentiert, bewertet und vergütet werden, entsteht eine schleichende Leistungserweiterung ohne Gegenleistung. Aus Sicht des Auftraggebers gilt: Mündliche Anweisungen im Sprint-Review binden den Auftragnehmer nicht zu einer kostenlosen Erweiterung – umgekehrt verpflichten sie ihn aber auch nicht, die Änderung überhaupt umzusetzen. Ein schriftliches Change-Request-Verfahren ist deshalb keine Bürokratie, sondern ein Schutzmechanismus für beide Seiten.
Abnahme und Abnahmefiktion: § 640 Abs. 2 BGB sieht vor, dass ein Werk als abgenommen gilt, wenn der Auftraggeber eine gesetzte angemessene Frist zur Abnahme verstreichen lässt, ohne einen Mangel geltend zu machen. Dieses Risiko wird in der Praxis unterschätzt. Wer auf eine Abnahmeaufforderung des Auftragnehmers nicht reagiert, kann die gesetzlichen Gewährleistungsrechte verlieren. Verträge sollten deshalb klare Abnahmefristen, Abnahmekriterien und das Recht zur Abnahme unter Vorbehalt regeln.
Mängeldefinition und Qualitätskriterien: Was ist ein Mangel bei agil entwickelter Software? Sofern keine Leistungsbeschreibung oder technische Spezifikation als Vertragsbestandteil vereinbart ist, richtet sich die Beschaffenheit nach der üblichen Beschaffenheit und dem, was der Auftraggeber nach Art des Werkes erwarten darf (§ 633 Abs. 2 BGB). Dieses Kriterium ist unscharf und streitträchtig. Akzeptanzkriterien pro User-Story, Lastenheft, Definition of Done: All das sind Werkzeuge, die im Vertrag rechtsverbindlich verankert werden müssen.
Urheberrecht und Nutzungsrechte: Software ist urheberrechtlich geschütztes Werk (§ 69a UrhG). Wer die Nutzungsrechte am Entwicklungsergebnis erhält, richtet sich nach dem Vertrag. Ein IT-Projektvertrag ohne ausdrückliche Nutzungsrechtseinräumung kann dazu führen, dass der Auftraggeber die entwickelte Software nach Projektabschluss nicht einsetzen, modifizieren oder weitergeben darf. Zu regeln sind mindestens: Ausschließlichkeit, sachlicher Umfang, Recht zur Modifikation und Quellcodeübergabe.
Haftungsbegrenzungen: Auftragnehmer versuchen regelmäßig, ihre Haftung auf die Vertragsvergütung oder auf grobe Fahrlässigkeit zu begrenzen. Zulässig sind solche Klauseln nur in den Grenzen der AGB-Inhaltskontrolle (§§ 305 ff. BGB) oder, bei individuell ausgehandelten Regelungen, im Rahmen des gesetzlich Zulässigen. Für den Auftraggeber bedeutet das: Haftungsklauseln müssen im Verhandlungsprozess aktiv verhandelt werden – eine bloße Hinnahme der Auftragnehmer-AGB führt im Schadensfall regelmäßig zu unbefriedigenden Ergebnissen.
Wie Geschäftsführer im Mittelstand persönliche Haftungsrisiken minimieren
IT-Projekte sind für den Mittelstand oft existenziell: Ein ERP-System, eine Produktionssteuerungssoftware oder eine Kundendatenplattform kann bei Scheitern Betriebsunterbrechungen, Umsatzverluste und Vertragsstrafen gegenüber Dritten auslösen. Der Geschäftsführer einer GmbH ist nach der Business Judgment Rule (§ 93 AktG analog, ständige Rechtsprechung) verpflichtet, bei wesentlichen unternehmerischen Entscheidungen auf der Grundlage angemessener Information zu handeln.
Was bedeutet das für IT-Projekte? Wer ein Softwareprojekt mit einem Volumen startet, das für das Unternehmen wesentlich ist, ohne die vertragliche Grundlage anwaltlich prüfen zu lassen, läuft Gefahr, die Sorgfaltspflichten gegenüber der Gesellschaft zu verletzen. Eine unzureichende Vertragsgestaltung, die zu einem vermeidbaren Projektschaden führt, kann die persönliche Haftung des Geschäftsführers gegenüber der Gesellschaft begründen.
In einem aktuellen Mandat beriet die Kanzlei einen mittelständischen Maschinenbauer aus dem Rhein-Main-Gebiet, der ein Produktionskontrollsystem auf agiler Basis hatte entwickeln lassen. Der Vertrag sah keine strukturierten Abnahmen, kein Change-Request-Verfahren und keine Übergabe des Quellcodes vor. Nach 18 Monaten war das System teilweise lauffähig, der Auftragnehmer insolvent, und die Nutzungsrechte an den entwickelten Modulen streitig. Ausgangslage: Projektbudget vollständig abgerufen, System nicht in Produktion. Vorgehen: Sicherung der urheberrechtlichen Nutzungsrechte über Insolvenzverwalter, Geltendmachung von Schadensersatzansprüchen gegen Verantwortliche. Ergebnis: Teilweise Rechtssicherung über Nutzungsrechte; Schadensersatzverfahren laufend. Der Fall illustriert, dass vertragliche Sorgfalt kein Kostenfaktor, sondern eine Versicherung gegen erheblich größere Schäden ist.
Welche Regelungen beim Vertragsabschluss zwingend zu treffen sind
Für mittelständische Auftraggeber empfiehlt sich eine strukturierte Checkliste der Mindestanforderungen an einen IT-Projektvertrag für agile Entwicklung:
- Vertragstyp explizit regeln: Werkvertrags- oder Dienstvertragscharakter für den Gesamtvertrag und für Einzelabrufe festlegen; keine offene Mischkonstruktion ohne Regelung der Rechtsfolgen.
- Leistungsumfang und Initialanforderungen: Ein initiales Lastenheft oder eine Produktvision als Vertragsbestandteil; Definition, wie Anforderungsänderungen dokumentiert und vergütet werden.
- Sprint- und Meilensteinstruktur: Verbindlicher Projektplan mit Sprints, Lieferterminen und definierten Deliverables pro Iteration.
- Abnahmeregeln: Abnahmezeitraum, Abnahmekriterien (Definition of Done, Akzeptanzkriterien), Regelung der Abnahmefiktion und des Vorbehaltsrechts.
- Änderungsmanagement: Schriftliches Change-Request-Verfahren mit Auswirkungsanalyse auf Termin und Budget vor Umsetzung.
- Urheberrecht: Ausdrückliche Einräumung ausschließlicher Nutzungsrechte, Quellcodeübergabe, Umgang mit Drittkomponenten (Open Source).
- Vergütung: Klare Regelung, ob Festpreis, Time & Material oder hybride Vergütung; Regelung für Mehraufwand aus Änderungsanforderungen.
- Gewährleistung und Support: Gewährleistungsdauer, Mängel-Kategorisierung (kritisch/nicht-kritisch), Reaktionszeiten, Übergang in Wartungsvertrag.
- Haftung: Individuell verhandelte Haftungsregelungen statt Übernahme der Auftragnehmer-AGB.
- Datenschutz: Auftragsverarbeitungsvertrag gemäß Art. 28 DSGVO, sofern personenbezogene Daten verarbeitet werden; Meldepflicht bei Datenschutzverletzungen binnen 72 Stunden (Art. 33 DSGVO) als Regelungsgegenstand.
Was tun, wenn ein IT-Projekt in die Krise gerät?
Gerät ein IT-Projekt in Schieflage, entscheiden die ersten Wochen über die Handlungsoptionen. Wer zu lange wartet, verliert Beweise, versäumt Fristen und vermindert seinen Verhandlungsspielraum. Wie reagiert man richtig?
Der erste Schritt ist die Dokumentation des Ist-Zustands: Welche Leistungen sind tatsächlich erbracht worden, welche zugesagten Leistungen fehlen, welche Mängel sind nachweisbar? Screenshots, Protokolle, E-Mails und Meetingmitschnitte sind Beweismittel, die gesichert werden müssen, bevor sie verloren gehen.
Der zweite Schritt ist die Prüfung des Vertragsverhältnisses: Werkvertrag oder Dienstvertrag? Welche Gewährleistungsrechte bestehen, welche Fristen sind bereits abgelaufen oder laufen demnächst? Die regelmäßige Verjährungsfrist nach § 195 BGB beträgt drei Jahre – für werkvertragliche Mängelansprüche gilt die spezielle Frist des § 634a BGB, die ab Abnahme zu laufen beginnt.
Der dritte Schritt ist die Prüfung außergerichtlicher Optionen: Ein belastbares Mängelprotokoll, kombiniert mit einer anwaltlichen Nachfristsetzung, erzeugt in der Praxis häufig die Bereitschaft zur Nacherfüllung oder zu einer einvernehmlichen Lösung. Ein streitiges Gutachtenverfahren oder ein selbstständiges Beweisverfahren (§§ 485 ff. ZPO) kann helfen, den technischen Befund gerichtsfest zu sichern, ohne sofort Klage erheben zu müssen.
Nach unserer Erfahrung lassen sich eskalierte IT-Streitigkeiten in einem erheblichen Teil der Fälle durch strukturierte außergerichtliche Verhandlungen lösen – vorausgesetzt, die rechtliche Position des Auftraggebers ist hinreichend belastbar dokumentiert und anwaltlich untermauert.
Datenschutz als Bestandteil des IT-Projektvertrags
Wer Software entwickeln lässt, die personenbezogene Daten verarbeitet, muss den Datenschutz von Anfang an mitverhandeln. Die DSGVO verpflichtet Verantwortliche, technische und organisatorische Maßnahmen bereits bei der Entwicklung zu berücksichtigen – das Prinzip „Privacy by Design" (Art. 25 DSGVO). Ein IT-Projektvertrag, der datenschutzrechtliche Anforderungen nicht adressiert, kann zu erheblichen Compliance-Risiken führen.
Sofern der Entwicklungsdienstleister im Auftrag Zugriff auf personenbezogene Daten erhält, ist ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO zwingend. Verstöße gegen die DSGVO können mit Bußgeldern von bis zu 20 Millionen Euro oder bis zu 4 Prozent des weltweiten Jahresumsatzes geahndet werden (Art. 83 DSGVO). Für mittelständische Unternehmen ist das Risiko damit nicht abstrakt.
Zu regeln sind im Vertrag: Verarbeitungszwecke, Weisungsgebundenheit des Auftragnehmers, Subunternehmer-Genehmigung, Datensicherheitsmaßnahmen, Rückgabe und Löschung von Daten nach Projektabschluss sowie Unterstützungspflichten bei der Bearbeitung von Betroffenenanfragen. Betroffenenanfragen nach Art. 15 DSGVO sind grundsätzlich innerhalb eines Monats zu beantworten – eine Frist, die auch den Auftragnehmer als Auftragsverarbeiter trifft.
Mandats-Illustration: In einem aktuellen Mandat beriet die Kanzlei einen mittelständischen Handelskonzern, der eine Kundendatenplattform auf Basis agiler Entwicklung einführen ließ. Der Auftragsverarbeitungsvertrag war zunächst nicht abgeschlossen worden; der Dienstleister hatte im Rahmen von Testläufen Zugriff auf Echtkundendaten erhalten. Ausgangslage: Datenschutzrechtliche Rüge durch den unternehmensinternen Datenschutzbeauftragten kurz vor Go-Live. Vorgehen: Kurzfristige Erarbeitung eines konformen Auftragsverarbeitungsvertrags, Dokumentation der technisch-organisatorischen Maßnahmen, Abstimmung mit der zuständigen Aufsichtsbehörde. Ergebnis: Projektstart ohne aufsichtsbehördliche Beanstandung; Compliance-Struktur für folgende Projekte etabliert. Das Mandat zeigt exemplarisch, dass Datenschutz kein Thema der Projektendphase ist.
Die vorstehende Darstellung betrifft die typischen Regelungsfragen bei IT-Projektverträgen und agiler Softwareentwicklung. Ihr konkreter Fall erfordert die Prüfung Ihres Vertragsentwurfs, der Projektdokumentation und der einschlägigen Fristen. Zur Klärung, wie die vertragliche Gestaltung auf Ihr Entwicklungsprojekt wirkt, wenden Sie sich an info@brandtfalk.com.
Verwandte Leistungen
Häufige Fragen zu IT-Projektverträgen und agiler Softwareentwicklung
Ist ein agiler IT-Projektvertrag rechtlich ein Werkvertrag oder ein Dienstvertrag?
Die Einordnung hängt nicht von der Vertragsbezeichnung, sondern vom geschuldeten Inhalt ab. Schuldet der Auftragnehmer einen konkreten Erfolg – ein funktionsfähiges System oder einen definierten Softwarestand –, liegt in der Regel ein Werkvertrag nach § 631 BGB vor. Schuldet er nur das Tätigwerden ohne Erfolgshaftung, ist ein Dienstvertrag nach § 611 BGB anzunehmen. Viele agile Projektverträge sind als Mischkonstruktionen ausgestaltet, die werkvertragliche Teilabnahmen mit dienstvertraglicher Aufwandsvergütung verbinden. Die genaue Einordnung ist im Einzelfall anwaltlich zu prüfen.
Was passiert, wenn keine Abnahme im IT-Projektvertrag geregelt ist?
Fehlt eine vertragliche Abnahmeregelung, greifen die gesetzlichen Abnahmevorschriften des Werkvertragsrechts (§§ 640, 641 BGB). Besonders relevant: Das Werk gilt gemäß § 640 Abs. 2 BGB als abgenommen, wenn der Auftraggeber auf eine Abnahmeaufforderung des Auftragnehmers nicht innerhalb einer angemessenen Frist reagiert, ohne Mängel zu benennen. Die Abnahmefiktion kann die Gewährleistungsrechte des Auftraggebers erheblich einschränken. Verträge sollten ausdrückliche Abnahmekriterien und -fristen enthalten.
Wer ist Inhaber der Urheberrechte an der entwickelten Software?
Urheberrechte entstehen originär beim schöpferisch tätigen Entwickler (§ 7 UrhG). Für den Auftraggeber entsteht kein automatisches Nutzungsrecht allein durch Zahlung der Vergütung. Der IT-Projektvertrag muss ausdrücklich regeln, welche Nutzungsrechte eingeräumt werden – insbesondere Ausschließlichkeit, Umfang, Recht zur Modifikation und Quellcodeübergabe. Ohne diese Regelung kann der Auftraggeber die Software nicht dauerhaft nutzen, anpassen oder weiterentwickeln lassen.
Welche Datenschutzanforderungen gelten bei agiler Softwareentwicklung?
Sofern der Entwicklungsdienstleister im Rahmen des Projekts Zugriff auf personenbezogene Daten erhält, ist ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO zwingend erforderlich. Zudem sind die Grundsätze von Privacy by Design und Privacy by Default (Art. 25 DSGVO) bei der Systemkonzeption zu berücksichtigen. Datenschutzverletzungen sind der zuständigen Aufsichtsbehörde binnen 72 Stunden zu melden (Art. 33 DSGVO). Verstöße können mit erheblichen Bußgeldern geahndet werden.
Kann ein IT-Projektvertrag bei Projektverzug gekündigt werden?
Ja – beim Werkvertrag steht dem Auftraggeber nach erfolgloser Nachfristsetzung das Recht zum Rücktritt oder zur Kündigung aus wichtigem Grund zu (§§ 636, 648a BGB). Die Kündigung ist mit Schadensersatzansprüchen kombinierbar, wenn der Auftragnehmer die Verzögerung zu vertreten hat. Beim Dienstvertrag ist eine ordentliche Kündigung nach den allgemeinen Regeln möglich; Schadensersatz setzt in der Regel Verschulden voraus. Die konkrete Handlungsoption hängt von der Vertragsgestaltung und dem Nachweis der Pflichtverletzung ab.
Die vorstehende Darstellung betrifft die Regelfälle der rechtlichen Einordnung von IT-Projektverträgen. Ihr konkreter Fall erfordert die Prüfung von Vertragsunterlagen, Projektdokumentation, laufenden Fristen und der einschlägigen Rechtsprechung. Für eine erste Durchsicht Ihrer Unterlagen erreichen Sie uns unter info@brandtfalk.com.
Dieser Beitrag dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung im Einzelfall dar. Er ersetzt nicht die anwaltliche Prüfung Ihres konkreten Sachverhalts. Für eine auf Ihre Situation zugeschnittene Beratung wenden Sie sich an info@brandtfalk.com.
Dieser Beitrag ist eine allgemeine Information und stellt keine Rechtsberatung dar. Für eine Prüfung Ihres Falls kontaktieren Sie info@brandtfalk.com.