Niemand streitet gerne, denn "Recht haben" heißt noch lange nicht "Recht bekommen". Dies gilt vor allem bei streitigen Verfahren mit IT-Bezug, unabhängig davon, ob dieses vor einem ordentlichen Gericht, einem Schiedsgericht oder einer Schlichtungsstelle erfolgt. Denn besonders bei streitigen Verfahren mit IT-Bezug stellen sich für die Parteien diverse Herausforderungen: So haben die Parteien, entsprechend ihrer Beweislast, oftmals langjährige und komplexe Sachverhalte intensiv aufzuarbeiten und verständlich vorzutragen, an denen nicht selten mehrere Fachabteilungen beteiligt sind. Zugleich fühlen sich vor allem die staatlichen Gerichte, die regelmäßig über keine derart speziellen technischen und rechtlichen Kenntnisse im IT-Bereich verfügen, überfordert und scheuen eine Entscheidung nach Aktenlage. Das oft für beide Parteien unbefriedigende Ergebnis: Ein umfangreiches Sachverständigengutachten wird eingeholt, welches den Rechtsstreit entscheidet.

Ein solches Ergebnis spiegelt selten die Interessen beider Parteien wider. Deshalb gilt es, solche Auseinandersetzungen vor allem bei langjährigen Softwareprojekten zu verhindern. Einfache, klare Spielregeln helfen bereits im Projekt, Streitigkeiten schnell zu beenden und so langjährige und kostenspielige Gerichtsverfahren zu vermeiden oder Gerichtsverfahren zu vereinfachen. Dies spart nicht nur Kosten, sondern auch Zeit.

1. Klartext - Was ist die Leistung?

Regelmäßig stellt sich erst während der mündlichen Verhandlung heraus, dass Auftraggeber und Auftragnehmer unterschiedliche Vorstellungen über die geschuldete Leistung hatten. Es ist deshalb unerlässlich, dass sich beide Parteien einig über die zu erbringenden Leistungen sind. Dies gilt unabhängig davon, ob die Software klassisch nach dem Wasserfallmodell erstellt oder agil programmiert wird.

Beim Wasserfallmodell handelt es sich um ein lineares Vorgehensmodell in der Softwareentwicklung, bei dem der Softwareentwicklungsprozess in einzelnen, festen Phasen organisiert wird. Das heißt, die Software wird auf Basis der Anforderungen des Auftraggebers zuerst vom Auftragnehmer konzipiert und im Anschluss programmiert. Dem Auftraggeber ist hierbei dringend anzuraten, seine Erwartungen an die Software zu Beginn des Softwareprojektes in einem sogenannten Lastenheft zu dokumentieren, so dass der Auftragnehmer, bestenfalls gemeinsam mit dem Auftraggeber, auf dieser Basis das sogenannte Pflichtenheft erstellen kann, welches die geschuldeten Funktionen der Software beschreibt.

Anders ist die Vorgehensweise bei der agilen Programmierung. Hier wird die Leistung iterativ, also schrittweise, bestimmt und fortentwickelt. Dennoch, auch in diesem Fall sollte seitens der Parteien Einigkeit darüber herrschen, was die vom Auftragnehmer konkret zu erbringende Leistung für die vom Auftraggeber zu zahlende Vergütung sein soll. Hierfür ist es in beiden Fällen erforderlich, dass der Auftraggeber in einem ersten Schritt seine Anforderungen an die Software identifiziert. Dies bedingt die rechtzeitige Einbindung aller für das Softwareprojekt zuständigen Fachabteilungen. Hierzu gehören regelmäßig die IT-, die Rechts- und die Einkaufsabteilung.

2. Gründlichkeit bei der Vertragserstellung

Unklare Verträgen sind einer der häufigsten Ursachen für Rechtsstreitigkeiten. Es gilt daher bereits bei Vertragserstellung an einen potentiellen Streitfall zu denken und den Vertrag auf Eindeutigkeit und Plausibilität zu prüfen.

Das bedeutet vor allem, dass die Parteien sowohl im Vertragsdokument an sich als auch in den zugehörigen Anlagen einheitliche Begriffe für die Leistungen verwenden und die Leistungen konkret und detailliert beschreiben. Von der Verwendung generischer Begriffe und Umschreibungen ist strikt abzuraten. Diese bergen nämlich nicht nur großen Auslegungsspielraum, sondern auch großes Konfliktpotential. Die Kontrollfrage lautet also: Würde ein Dritter, der nicht bei der Vertragshandlung zugegen war, den Vertrag genauso verstehen?