Sechs typische Fehler beim IT-Projektvertrag

IT-Projekte sind sehr komplex und überfordern gerade mittelständische Unternehmen. Oft fehlt es an einschlägiger Projektmanagementerfahrung und dem technisch-juristischen Know-how. Der nachfolgende Beitrag soll für einige Fehlerquellen sensibilisieren, die bei IT-Projektverträgen regelmäßig zu beobachten sind.

1.  Konkrete Beschreibung des Projektgegenstands

Selbst wenn die Projektpartner schon umfangreiche Gespräche über den Gegenstand, den Ablauf und das Ergebnis eines Projekts geführt haben, fällt es ihnen regelmäßig schwer, den konkreten Leistungsgegenstand klar und verständlich „aufs Papier zu bringen“. Dies birgt die Gefahr, dass die Erwartungen der Beteiligten an den Leistungsgegenstand stark voneinander abweichen. Da die Abweichungen regelmäßig erst im Rahmen der Projektausführung zu Tage treten, droht das Projekt zu scheitern oder es verzögert oder verteuert sich erheblich.

Praxis-Tipp 1: Das oben beschriebene Szenario lässt sich vermeiden, wenn der Vertragsgegenstand so weit konkretisiert wird, dass jedermann ohne weiteres nachvollziehen kann, ob und wann die Projektleistung vollständig und mangelfrei erbracht worden ist. 

In der klassischen Softwareprogrammierung werden die Leistungsanforderung in der Regel im Rahmen eines Pflichtenhefts (https://de.wikipedia.org/wiki/Pflichtenheft) definiert, das dem Projektvertrag als Anlage beigefügt wird.

Bei agilen Programmierungsmethoden sind sich die Vertragsparteien zwar über das Ziel des Projekts einig, wollen sich aber nicht auf einen konkreten Weg festlegen, um möglichst flexibel auf sich ändernde Projektanforderungen reagieren zu können.

Praxis-Tipp 2: Bei agiler Programmentwicklung kann der Leistungsgegenstand durch Funktionsanforderungen (z.B. das Definieren von User Stories: https://de.wikipedia.org/wiki/User_Story) spezifiziert werden.

2.  Vereinbarung von Meilensteinen

Für den Auftraggeber ist die zeitliche Umsetzung des Projekts regelmäßig von besonderer Bedeutung; nicht nur dann, wenn es um zeitkritische Projekte geht. Zieht sich ein Projekt lange hin, drohen überdies hohe Kosten und Ressourcenbindung. Aber auch der IT-Dienstleister hat ein Interesse, seine Ressourcen besser einplanen zu können.

Praxis-Tipp 3: Die Parteien vereinbaren bestimmte Meilensteine, für die Umsetzung der Projektziele (siehe Ziff. 1). Dabei kann die Zahlung einer (Teil-)Vergütung vom Erreichen bestimmter Meilensteine abhängig gemacht werden.

3.  Mechanismus zur Mängelbeseitigung und Anforderungsänderung

Oft fehlen klare Regelungen zum Umgang mit Leistungsmängeln und -verzögerungen im Rahmen der Projektausführung. Zwar sieht das deutsche Recht ein sehr ausgewogenes Regime für den Umgang mit Leistungsmängeln und -vezögerungen bei Dienst- und Werkverträgen vor, auf das sich die Vertragsparteien notfalls stützen können. Die gesetzlichen Regeln werden der Praxis von Projektverträgen aber nicht in allen Fällen gerecht oder jedenfalls fehlen pragmatische Lösungsansätze für einen zügigen und effektiven Umgang mit Mängeln und Verzögerungen. Ähnliches gilt für notwendige Änderungen der Projektanforderungen, die sich erst im Rahmen der Projektausführung zeigen. Auch für den Umgang mit diesen Change-Requests bieten die gesetzlichen Regelungen keinen adäquaten Rahmen.

Praxis-Tipp 4: Bei komplexen IT-Projekten sollte der Projektvertrag konkrete Regelungen zum Umgang mit der Dokumentation und der Anzeige von Mängeln, zur Vorgehensweise bei der Mängelbehebung (wer macht was?), der Suche nach Lösungswegen bei Uneinigkeit über das Vorliegen von Mängeln (z.B. Inanspruchnahme eines Schiedsgutachters) und zur Bearbeitung von Change-Requests (von der Anzeige, über die Ausführung und die Kostentragung) enthalten. 

4.  Transparente Vergütungsregeln

Der IT-Dienstleister hat in der Regel kein Interesse an der Vereinbarung von Festpreisen, weil der tatsächliche Projektaufwand nur schwer im Voraus zu kalkulieren ist. So besteht die Gefahr, dass das ganze Projekt unrentabel wird. Andererseits können die Projektkosten aus Sicht des Auftraggebers schnell aus dem Ruder laufen und das vorgesehen Budget übersteigen, wenn ein transparenter Vergütungsrahmen fehlt.

Derartige Konflikte können vermieden werden, wenn die Beteiligten vor Projektbeginn für Kostentransparenz sorgen.

Praxis-Tipp 5: Es bieten sich unterschiedliche Tools zur Schaffung von Transparenz an: 

• Vergütung nach Teilschritten bzw. Abschlagszahlungen bei Erreichen von Meilensteinen (siehe Praxis-Tipp 3),
• Vereinbarung von Caps oder Kostenschätzungen, 
• Vereinbarung angemessener „Puffer“ bei unerwarteter und erheblicher Erhöhung des Aufwands
• Regelungen zur Vergütung bei vorzeitigem Exit oder Anforderungsänderungen

5.  Projektverantwortung, Eskalationsstufen

Oft wird die Bedeutung der Projektorganisation für den Erfolg eines IT-Projekts unterschätzt. Ein guter IT-Projektvertrag sollte die Auswahl der Projektverantwortlichen, die Steuerung der Kommunikation und die Eskalationsmöglichkeiten nicht dem Zufall überlassen.

Praxis-Tipp 6: Benennung mindestens eines verantwortlichen Ansprechpartners für jeden Projektbeteiligten, Festlegung einzuhaltender Kommunikationswege (per E-Mail, Ticket-System etc.) und Schaffung eines Eskalationsmechanismus für den Fall des Auftretens von Differenzen.

6.  Urheber- und Nutzungsrechte an Software

Oft werden nur unzureichende Standardklauseln verwendet, die der Komplexität und Realität des IT-Projekts nicht gerecht werden. Spätestens dann, wenn die Projektpartner die Zusammenarbeit beenden oder der Auftraggeber die Nutzung der Software ausweiten möchte (z.B. durch Outsourcing), stellen sich Fragen über die Rechteinhaberschaft. Spannend wird es, wenn unterschiedliche Akteure an dem Projekt beteiligt sind und sich diese (bzw. deren Mitarbeiter) auf die Vorschriften zum Miturheberrecht berufen können. Fehlen konkrete Regelungen im Projektvertrag, birgt dies erhebliche Risiken für alle Projektbeteiligten.

Praxis-Tipp 7: Erstellung maßgeschneiderter Klauseln zur Rechteeinräumung, die Art und Umfang der Rechteeinräumung genau definieren und ggf. eine Kaufoption des Auftraggebers für den Fall vorsehen, dass dieser die Zusammenarbeit mit dem IT-Dienstleister beenden möchte.

Die Informationen in unseren Beiträgen dienen lediglich der Information. Sie stellen keine Rechtsberatung dar und können eine individuelle rechtliche Beratung, welche die Besonderheiten des Einzelfalles berücksichtigt, nicht ersetzen.