Die 13 teuflischsten Fallen bei Projektverträgen

iBusiness-Autor Christoph Kappes ist gelernter Jurist, hat das aber überwunden. Der Geschäftsführer des Beratungsunternehmens Fructus   hat in 18 Jahren rund 1.000 Projekte abgewickelt. Und freut sich immer wieder, wenn dieselben Fallen in den Verträgen auftauchen.
Seine 13 Projektfallen-Lieblinge:

1. Rechtemanagement: Beim Rechtemanagement ist ein verbreiteter Irrglaube, man brauche nur eine bestimmte Standardklausel durchzusetzen und dies sei ein rein juristisches Thema. Reingefallen! Die Frage, an welchem Gegenstand diese Rechte eingeräumt werden, ist nicht minder wichtig.
   
   
2. 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!
   
   
3. 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.
   
   
4. 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.
   
   
5. 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

6. 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ögensschadenshaftpflicht-Versicherung zu orientieren und für Sachschäden aus nicht-vorsätzlichem Handeln ein Multiples vom Auftragswert als Haftungsobergrenze vorzusehen.
   Auftragnehmer ü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.
   
   
7. 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.).
   
   
8. 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.
   
   
9. 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.

10. Reporting ist 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.
    
    
11. 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.
    
    
12. 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.
    
    
13. Verhandlungsstrategien: Ich halte jedoch nicht viel vom Griff in diese Trickkiste, weil die Gegenseite in der Regel eine ähnliche Verhandlungskompetenz besitzt und die Anwendung dieser Mittel an nonverbalen Signalen gut erkennen kann. Auch verhalten sich Profis mitunter absichtlich regelwidrig, um zu täuschen - beispielsweise durch systematisches Lob des Gegenübers oder einen lockeren Plauderton. Wer dem gegenüber nur auf Lehrbuchwissen angewiesen ist, kann mehr Schaden anrichten als Nutzen stiften.
    Man sollte wenigstens einige der klugen Bücher lesen, die dazu geschrieben worden sind, damit man die Gegenseite einschätzen kann. Denn einige Verhandlungspartner bedienen sich aus dieser Trickkiste, zum Beispiel beim Auftreten von "Sekundanten", bei Abbrüchen zum Schein, Aufschieben und "Vergessen", überraschenden Klauseln und Nebelbomben. (Hierzu gehören als kleineres Übel auch rhetorische Figuren wie "Diese Klausel ist nur für den Notfall, darauf haben wir uns noch nie berufen", die "Schallplatte mit Sprung" und das Nutzen von Regeln über Auftreten und Körpersprache).
    Viel eher führt der gerade Weg zum Ziel, zumal er die künftige Leistungsbeziehung nicht schädigt und in unserer kleinen Branche den Ruf nicht ruiniert.

Juristen und Informatiker begegnen sich mitunter wie Menschen aus anderen Welten. In der Tat haben beide Welten ihre Denkgebäude und Fachausdrücke, die eine Hürde zum gegenseitigen Verstehen sind. So entsteht mitunter der Eindruck, der jeweils andere sei ein umsetzender "Klempner". Beide Welten haben aber verblüffende Ähnlichkeit: methodisch versuchen beide, durch gedanklich Vorwegnahme aller möglichen Situationen abstrakte Perfektion zu erreichen, der Jurist durch eine "Monsterklausel", der Informatiker durch komplexen Code. Beides erfordert vom Vorgehen her Kreativität und Vorstellungsvermögen und beides führt zu "harten", hieb- und stichfeste Ergebnissen. Wenn beide Welten dieses Verbindende sähen, wäre für die Zusammenarbeit viel gewonnen.