Wir haben in unseren Seminaren und in den Beiträgen zu diesem Thema folgende Thesen vertreten:
I: Der Projektvertrag ist kein Modell des BGB
1.) Verständnis dessen, was ein Projektvertrag ist
Ein Projektvertrag ist ein Vertrag, der auf die Erreichung eines Zieles gerichtet ist. Allerdings ist die Planung zum Zeitpunkt des Vertragsabschlusses noch nicht abgeschlossen. Gemeinsamer Nenner ist der Umstand, dass sich während der Erstellungsphase Parameter ändern, die für die Bestimmung des Ziels wesentlich sind. Das können neue Erkenntnisse des Kunden über die endgültige Struktur des Kunden sein, neue technische Erkenntnisse oder es ändern sich während des Realisierungsprozesses Gesetze oder faktische Gegebenheiten. Eine Metapher dazu: Eine Reisegruppe sagt, wir wollen von Hamburg nach Italien reisen. Wohin genau, hängt von den Dingen ab, die wir wissen, wenn wir Italien erreicht haben.
2.) Das deutsche Recht beinhaltet keinen eigenständigen Typ „Projektvertrag“
Das deutsche Schuldrecht (also das Recht über die Austauschverträge wie z.B. Kauf, Schenkung, Werkvertrag, Miete und Dienstvertrag) kennt zwei Gruppen von Verträgen:
Entweder es besteht wie im Rahmen von Werk-, Kauf- oder Mietverträgen ein konkreter Konsens über den Sollzustand, der durch den Vertrag zu erbringen ist. Das aber setzt voraus, dass der Konsens so konkret ist, dass der erreichte Istzustand gegen den Sollzustand abgeglichen werden kann. Das deutsche Recht leitet den Sollzustand nicht nur aus dem eindeutig beschriebenen Vertragstext – der Leistungsbeschreibung – ab, sondern besagt vereinfacht, dass nicht nur die eindeutig beschriebenen Funktionen und Eigenschaften abzuliefern sind, sondern auch diejenigen, die nach dem normalen Verständnis mit zur Erreichung des Vertragszwecks erforderlich sind, oder die man erwarten kann, weil sie marktüblich sind. Aber der Ausgangspunkt dieser Verträge ist der Konsens der Parteien über den Sollzustand der Sache. Unterliegt der Sollzustand ständigen Änderungen, wie es typisch für das Gesellschafts- oder Eherecht ist, kennt das Schuldrecht nur noch den Typ des Dienstvertrags. Geschuldet wird also nicht ein bestimmtes Ergebnis – was das ist und wie zu überprüfen ist, ob das erreicht wurde kennen die Typen des Gesellschafts, Eherechts, Dienstvertragsrechts nicht – sondern eine bestimmte Form der Zusammenarbeit. Das Recht bestimmt nur ganz grob im Rahmen des Schadensersatzrechts, wie die Parteien zu arbeiten haben und überlässt die tägliche Arbeit und die Findung des täglichen Konsenses den Parteien.
Der Projektvertrag aber will ein Ziel erreichen, was dafür spricht, ihn als Werkvertrag zu qualizieren. Aber das unstetige des Konsenses spricht für die Einordnung als Dienstvertrag.
Und zwischen diesen Stühlen sitzt man eben, wenn man im Jahre 2014 einen „Projektvertrag“ nach Maßgabe des BGB´s aus dem Jahr 1900 erstellen will.
II.) Die Antwort liegt ausschließlich in Verträgen, die vom Gesetz abweichen
Das BGB ist anwendbar, wenn man keine abweichenden Regelungen trifft, enthält aber keine befriedigenden Antworten zum Thema „Projektvertrag“. Die Auswahl des richtigen Vertragstyps ist deshalb so derart wichtig, weil Rückabwicklungsansprüche unter dem Thema der Haftung eben juristisch nicht vernünftig zu begrenzen sind. Mal abseits des Punktes, dass Kunde und ITler den Erfolg des Projekts wollen. Aber ganz, ganz deutlich: Der Erfolg des Projekts hängt von der Auswahl der Methodik und des richtigen Vertragstyps ab. Der ITler tut sehr gut daran, den Kunden über diesen Punkt schon bei den Anbahnungsgesprächen zu informieren.
In unseren Vertragsmodulen für die Erstellung oder Anpassung von Software bieten wir unseren Kunden vier verschiedene Vertragstypen an. Jeder Vertragstyp hat seine Besonderheiten.
1.) Der einstufige Vertrag (Erstellung nur gegen Lastenheft und Workshop-Protokoll) hat den Vorteil geringer administrativer Kosten und ist dem Kunden im Verkaufsstadium auch gut zu vermitteln. Seine ganz klaren Schwächen aber sind: Bei der Erstellung von Software eignet er sich nur für kurze Projekte. Bei der Anpassung von Software geht ein großes Risiko ein, wer über keine gute Leistungsbeschreibung der Standardsoftware verfügt. Das Verfahren zum Nachführen des Konsens ist ausgesprochen unbefriedigend. Die Abgrenzung zwischen echtem und unechtem Change ist immer eine Sache der Auslegung. Spielt der Kunde nicht mit, dann lebt der ITler mit der ständigen Bedrohung des Rücktritts vom Vertrag durch den Kunden. Ein Risiko, das Versicherungen nicht abdecken.
2.) Die Mehrstufler (V-extended) erfordern einen hohen administrativen Aufwand, verursachen Kosten und entschleunigen Projekte. Dafür sind sie fair und sicher.
3.) Agile Projektmethodiken wie Scrum haben keinen derart hohen administrativen Aufwand, weil der Sollzustand bei weitem nicht so genau und gut beschrieben wird, wie im Werkvertragsrecht. Die Methodik trägt nicht umsonst den Namen Scrum. Sie sind schneller und kosten weniger. Rechtlich ist der Kunde benachteiligt. Beim Scheitern des Projekts steht ihm keine rechtliche Handhabe zu.
