Als Anwalt hat man zugegebenermaßen einen verstellen Blick auf IT-Projekte, denn natürlich landen gerade die auf dem Schreibtisch, bei denen irgend etwas schief gegangen ist. Von daher mag der Eindruck trügen, dass alle Projekte problematisch sind. Vielleicht wird sogar eine große Anzahl unspektakulär, still und zur Zufriedenheit aller Beteiligten abgewickelt.
Aber irgendwie bezweifle ich das.
Nun lebe ich natürlich von dem beschriebenen Scheitern, dennoch wundert es mich, dass es immer wieder dieselben Punkte sind, mit denen da mein Lebensunterhalt gesichert wird. Einer der beliebtesten Fehlerquellen ist, dass die Parteien eines IT-Projektes sich streiten, weil sie irgendwann schlicht nicht (mehr) wissen, was sie eigentlich vertraglich vereinbart haben.
Entgegen der landläufigen Meinung ist es nämlich nicht so, dass Verträge ein Stück Papier sind, das (nur) vom Hausjuristen oder Anwalt gut geschrieben sein muss, dann funktioniert das schon. Selten nämlich scheitert ein IT-Projekt an der mangelhaften Abfassung der Salvatorischen Klausel (Sie wissen schon: „Sollten eine oder mehrere Bestimmungen dieses Vertrages nichtig oder undurchführbar sein…“). Meist ist den Partein nach Wochen, Monaten und Jahren gar nicht mehr klar, was in der Sache vereinbart war. Eine Partei ist dann der Ansicht, dass eine bestimmte Arbeit geschuldet war, die andere nicht. Oder einer meint, eine bestimmte Arbeit sei Mängelgewährleistung und müsse umsonst durchgeführt werden, der andere geht von einer Auftragserweiterung aus, die zu bezahlen ist. Irgendwann ist jede Partei der Meinung, von der anderen Seite vorsätzlich geschnitten zu werden, man beginnt, Zahlungen oder Leistungen zurückzuhalten, der Ton wird schärfer, die Kommunikation wird nur noch über Dritte (eben etwa Anwälte) geführt – was die Sache meist erst recht eskaliert. Jeder beruft sich dann auf seine Sicht des Vertrages, jeder fühlt sich im Recht. Aber ist er das auch?
Und was ist (inzwischen) eigentlich der Vertrag? Was ist vereinbart?
Natürlich ist damals bei Vertragsschluss (eben vor Wochen, Monaten, Jahren) schon an der Leistungsbeschreibung, am Projektplan gespart worden, man hat eben einfach mal anfangen. Geschludert hat man an der Vorbereitung, an der Leistungsbeschreibung, an Milestone-Plänen, am Pflichten- und Lastenheft. Schon die Ausgangslage ist also zweifelhaft.
Aber – und hier ist die Crux – ein Vertrag für ein komplexes Projekt ist selten statisch, er lebt. Ändert sich das Projekt, ändert sich auch das Vereinbarte.
Später hat es daher – man stößt bei jedem Projekt ja auf unerwartetes und ungeplantes – unzählige Meetings (ohne Protokoll), Faxe, Emails (auf allen möglichen Ebenen vom „einfachen“ Mitarbeiter bis zum Geschäftsführer), Briefings und Unterredungen informeller Art gegeben. Jeder hat mal mitgeredet, oft mit dem PM, oft ohne.
Jeder einzelne dieser Punkte kann den ursprünglichen Vertrag geändert und insbesondere erweitert haben. Da können Parallelverträge geschlossen worden oder die ursprüngliche (schon insuffiziente) Leistungsbeschreibung ins Gegenteil verkehrt worden sein.
Auch das muss aber nicht sein – wer will schon nachvollziehen, ob da jede Emails von einer vertretungsberechtigten Person geschrieben wurde, oder ob durch die vielen Projektmeetings vielleicht eine Anscheins- oder Duldungsvollmacht entstanden ist? Ohne Vollmacht aber kein neuer Vertragsschluss bzw. keine Vertragsänderung.
Wer kann nach Jahren noch nachvollziehen, ob eine bestimmte Absprache eine Änderung oder nur eine Konkretisierung einer (ursprünglich schon schlecht gefassten) Leistungsbeschreibung war? Wer kann noch wissen, ob eine bestimmte informelle Unterredung nur ein „vielleicht sollten wir mal X und Y versuchen“ war oder doch schon ein „und ab nun versuchen wir X und Y“? Was genau war damals gemeint? Wer will vor allem die Kette nachvollziehen, in der ein bestimmter Punkt der zu erbringenden Leistung verformt wurde von den ursprünglichen Vorstellungen der Parteien in der Leistungsbeschreibung über viele Emails, Memoranden und Besprechungen von unterschiedlichen Leuten mit unterschiedlichen Terminologien und Erfahrungshorizonten?
Diese Vorgänge lassen sich meist selbst von den Beteiligten nicht mehr komplett rekonstruieren. Umso weniger darf man dann eine sachgerechte Beurteilung von Institutionen wie Anwälten, Gerichten und externen Sachverständigen erwartet. Hier lässt man sich auf ein Glücksspiel ein. Anders – und ein wenig philosophischer – ausgedrückt: es gibt einen Punkt, an dem es nicht mehr die Wahrheit über den Vertrag und das, was darin vereinbart war gibt, sondern ganz viele Wahrheiten.
Die Vermeidung von Problemen muss daher im Vorfeld ansetzen, schon bei Vertragsverhandlung und Vertragsschluss. Es geht nicht anders, auch wenn es lästig erscheint:
- Die Parteien müssen gemeinsam Kriterien entwickeln, wann eine vertragsgemäße Leistung vorliegt, Lasten- und Pflichtenhefte, Leistungsbeschreibungen, Milestone-Pläne o.Ä. erstellen; das ist letztlich wichtiger als ein ausgefeilter juristischer Textteil des Vertrages.
- Es muss klar getrennt werden zwischen Auftragserweiterungen (die es in jedem IT-Projekt gibt) und Mängelbeseitigung (etwas, das beauftragt wurde, geht nicht). Erstaunlicherweise geschieht gerade das nie.
- Vertragsänderungen sollten nur schriftlich oder schriftlich bestätigt erfolgen können, schon der Nachweisbarkeit halber.
- Die Parteien müssen sich auf eine klare, vornehmlich durch ein schriftliches Protokoll begleitete Abnahmeprozedur einigen, die dann auch tatsächlich eingehalten wird. Was abgenommen wurde gilt (wenn nicht versteckte Mängel vorliegen) dann als Erfüllung des Vertrages, d.h. wenn hier weitere Wünsche kommen, stellen diese klar eine weitere Beauftragung dar.
- Gerade für den Fall von Problemen muss der Vertrag Lösungen vorsehen, die nicht eskalieren, sondern de-eskalieren. Zurückbehaltungsrechte etwa ausschließen und stattdessen Zahlungen an Treuhänder vorsehen, wenn (vermeintlich, das ist ja immer gerade streitig) eine Partei Pflichten verletzt.
- Zuletzt muss – abseits des rechtlichen – die Kommunikation zwischen den Parteien immer offen bleiben. Ziehen sich die Beteiligten zurück, wechseln Ansprechpartner zu oft, bricht der Kommunikationsfluss ab, läutet das oft die Endphase des Projekts ein.
Über den autor
+49 89 28634-446 
arne.trautmann@snp.law Aktuelles
Weitere Beiträge des Autors
BGH zu Affiliate-Marketing: Alles ist schrecklich, aber Amazon haftet trotzdem nicht für seine Partner
Amazon muss nicht für seine Affiliate-Partner haften, entschied der Bundesgerichtshof. Rechtlich ist das Urteil kaum zu beanstanden, aber trotzdem hinterlässt es einen bitteren Nachgeschmack. Eine Einschätzung von Arne Trautmann. (mehr …)
DAO: Die codierte Organisation
Haben Sie schon jemals darüber nachgedacht, was sich hinter dem Begriff „dezentralisierte autonome Organisation“ (DAO) verbirgt und welchen Einfluss die DAO im Alltag hat? Arne Trautmann berichtet aus der Fachwelt. (mehr …)