Im Blog „Fruchtmark“ erscheinen Beiträge zu Strategie und Praxis des Digital Business – unregelmäßig, pointiert und gern „gegen den Strich“.

(Dies ist Teil 3 einer Serie – Teil 1 ist hier und Teil 2 hier.)

Außer dem Prozess der Verhandlung und den Gestaltungsmöglichkeiten zur Kostenseite gibt es eine Vielzahl weiterer Aspekte bei IT-Projektverträgen, die zu regeln sind. Dieser Teil der Serie fasst die Aspekte für den wichtigsten zweiten Bereich zusammen: das Management von Rechten und Risiken.

Rechtemanagement: In diesem Bereich ist ein verbreiteter Irrglaube, man brauche nur eine bestimmte Standardklausel durchzusetzen und dies sei ein rein juristisches Thema. FAIL! Die Frage, an welchem Gegenstand diese Rechte eingeräumt werden, ist nicht minder wichtig und eine beliebte Falle in der Praxis:

• Wenn vom Auftragnehmer selbstentwickelte Frameworks verwendet werden, sind für diese differenzierte Regelungen zu treffen. Allein die Übertragung nicht-ausschließlicher Rechte genügt den Bedürfnissen des Auftragnehmers nicht, vielmehr kommt es auf das Recht zur Weiterbearbeitung und die Qualität der Dokumentation an!


• In diesem Zusammenhang ist auch die Regelung zur „Übergabe von Quellcode“ zu sehen. Hier tauchen unter anderem Fragestellungen nach zugehörigen Projektdateien und ggf. auch Entwicklungswerkzeugen auf. IT-Verantwortliche sind also gut beraten zu prüfen, ob sie mit dem, was sie bekommen, auch wirklich etwas anfangen können.


• Bei SaaS-Lösungen ist auch die Herrschaft über Daten ein Knackpunkt. Der Anbieter muss zwar System- und Kundendaten auf einer gewissen Ebene verarbeiten können, es muss jedoch klar geregelt sein, dass diese Daten dem Auftraggeber gehören und auch, wie diese Daten bei Vertragsbeendigung an den Auftraggeber übergeben werden.


• Last, but not least, ein Klassiker: Ich habe leider Fälle erlebt, in denen von Vertriebsmitarbeitern Behauptungen ins Blaue hinein aufgestellt wurden, die zwar wesentliche Produkteigenschaften betrafen, vertraglich aber nicht dokumentiert wurden. Die vertragliche Dokumentation von Unterlagen und Behauptungen des Auftragnehmers in der Sales-Phase ist daher empfehlenswert.

Risikomanagement: Einige Themen liegen von Natur aus zwischen der juristischen und der IT-Welt und müssen einheitlich kommerziell und juristisch gelöst werden.

• Die Angemessenheit von Haftungstatbeständen und –grenzen gehört dazu. Wirtschaftlich muss aus Sicht des Auftragnehmers die Gewinnchance in einem angemessenen Verhältnis zum Haftungsrisiko sein. Es empfiehlt sich also, Haftungsgrenzen erstens an einer abzuschließenden Vermögensschadenshaftplicht-Versicherung zu orientieren und für Sachschäden aus nicht-vorsätzlichem Handeln ein Multiple vom Auftragswert als Haftungsobergrenze vorzusehen. Auftragnehmern übersehen allerdings hier gern, dass die Zahlung der Versicherung kein Selbstgänger ist und sie auf dem Haftungsrisiko in vielen Fällen sitzen bleiben. Denkbar ist als Alternative, den vertraglichen Haftungstatbestand an die Versicherungsbedingungen zu koppeln oder den Zahlungsanspruch an den Auftraggeber abzutreten, falls der Versicherer dies erlaubt.


• Die Verzahnung von Zahlungsplänen mit (Fix-)Terminen, Verzugsfolgen und Abnahme(n) können von Standards je nach Projekttyp abweichen. Zwei Beispiele zu letzterem sind die Fehlerfreiheit eines Systems in einer Stabilitätsphase und die vielen Möglichkeiten einer Vertragsstrafe (pauschalisiert, gestaffelt, mit und ohne Zusatzfristen, Deckelung etc.).


• Ich diskutiere auch gern neuartige Klauseln, um die Risiken für beide Seiten zu verteilen oder zu verschieben. Beispiel: Hinsichtlich der kritischen Schnittstellen zu Backend-Systemen, die eigentlich eine Beistellung des Auftraggebers sind, gibt der Auftragnehmer eine Erklärung über Vollständigkeit und Nachvollziehbarkeit ab. Generell neige ich dazu, Dinge, die mir „durch den Kopf gehen“ und die in Standardverträgen nicht geregelt sind, einmal umgangssprachlich zu formulieren und dem Vertragspartner vorzuschlagen.


• Des weiteren gehört zum Bereich des Risikomanagements ein Regelungskomplex für den Fall, dass der Auftragnehmer in die Krise gerät, von einer Escrow-Vereinbarung bis zur Vertragsbeendigung, die dem Insolvenzverwalter möglichst kein Recht lässt, ex post in die Vertragssituation einzugreifen.

Reporting: Eigentlich ein operatives Thema. Da es aber in der Projektpraxis immer wieder vorkommt, dass gerade in der Krise das Reporting vernachlässigt wird, würde ich es bereits im Projektvertrag granular festlegen, zum Beispiel mit der Vereinbarung eines Reportingformulares.

Dokumentation: Standardklauseln über Dokumentation sind nicht immer angemessen. Denn gerade im Digital Business werden häufig agile Entwicklungsmethoden verwendet. Diese Methoden postulieren zwar nicht den Verzicht auf eine Dokumentation, fordern aber einen klaren Nutzen. Agile Manifesto: Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen. Hier sollte der Auftraggeber sich genau überlegen, ob er wirklich eine Dokumentation im hergebrachten Sinne braucht. Wenn ja, ist diese nachträglich zu erstellen. Wenn nein, sollten die Dokumenttypen – je nach verwendetem Prozess, z.B. XP oder Scrum – exakt beschrieben werden, denn die softwarerechtlich üblichen Klauseln passen hier nicht! Das ist ein Sonderthema, das einen eigenen Artikel wert wäre.

Konkurrenzschutz: Hierzu ist schließlich erwähnenswert, dass es weit mehr Spielarten gibt, als ein „knallharter“ Ausschluss, für Wettbewerber des Auftraggebers nicht tätig werden zu dürfen – denn hierauf lassen sich Auftragnehmer häufig nur sehr ungern ein. Neben Positivlisten mit konkreten Wettbewerbern lässt sich Konkurrenzschutz auch nach Projektgegenstand, Leistungsart, Wettbewerbergattung und Dauer differenzieren. Wenn man hier die richtigen Parameter wählt, ist eine Einigung leichter zu erreichen.