1. IT-Projektvertrag – der Versuch ein bewegliches Ziel zu erfassen
Ein IT-Projekt ist eine Reise ins Ungewisse. Niemand weiß zu Beginn eines IT-Projekts, welche Probleme hinter den unmittelbar sichtbaren Problemen lauern. Niemand weiß, welche neuen Wünsche beim Kunden noch aufkeimen, wenn das Ergebnis des IT-Projekts sukzessive greifbarer wird. Niemand weiß, wie tiefgreifend die Änderungen sind, die neu hinzutretende Anforderungen an das IT-Projekt verursachen. Und dennoch muss im Zeitpunkt des Abschluss eines IT-Projektvertrags eine Einigung über Zeit und Budget erfolgen – zumindest als Schätzung. Kostenanschlag und Aufwandschätzung sind dann zwangsläufig am darauffolgenden Tag veraltet. Die Grenze zwischen der Konkretisierungen eines IT-Projekts (die im Rahmen dessen liegen, was man im Zeitpunkt des Abschlusses des IT-Projektvertrags erkennen konnte) und Änderungen des IT-Projekts (die unvorhergesehenen Aufwand verursachen) verläuft fließend. Eine ausgewogene Vertragsgestaltung von IT-Projektverträgen muss die sich hieraus ergebenen Risiken
zwischen den Parteien verteilen.
2. IT- Projektverträge als Werkverträge
Die Bestimmung des auf IT-Projektverträge anwendbaren Vertragstyps insbesondere des Werkvertragsrechts oder des Dienstvertragsrechts wird in der Fachliteratur kontrovers diskutiert. Manche halten sogar eine Gelegenheitsgesellschaft als GbR gemäß §§ 705ff. BGB durch ein IT-Projekt für möglich. Hieran kann man in der Tat denken, wenn die Parteien gemeinsam loslaufen und (wie bei einer gemeinsamen Unternehmung) nur sehr ungenau wissen wohin. Doch in normalen Auftraggeber/Auftragnehmer-Konstellationen würde eine GbR dem Parteiwillen nie gerecht. Auch wenn oft vieles unklar ist, so ist doch fast immer klar, dass eine Partei das Ergebnis des IT-Projekts schaffen soll, während die andere Partei das IT-Projekt bezahlt und das Ergebnis verwerten will. So bleiben Werk- und Dienstvertrag als mögliche Vertragstypen. Die Abgrenzung ist in der Theorie klar: Ein Werk ist alles, bei dem der Auftragnehmer ein Ergebnis schuldet. Und das ist bei IT-Projekten meist der Fall, es sei denn der Auftragnehmer stellt nur Ressourcen bereit, auf die ein Auftraggeber zugreift, der das Projekt selbst steuert und den Weg zum Projektergebnis selbständig kontrolliert. Wenn Auftragnehmer die Vertragsmuster für den IT-Projektvertrag stellen, versuchen sie manchmal, die eigene Rolle klein zu definieren und sich lediglich als Unterstützungsdienstleister zu positionieren, der dem Auftraggeber nur zuarbeitet. Eine solche Positionierung entspricht aber in den seltensten Fällen den Erwartungen des Auftraggebers. Diese Erwartung wird in der Regel auch durch Marketingkommunikation und vorvertragliche Kommunikation vom Auftragnehmer genährt, wenn dieser sich als Experte für einen bestimmten Typ von IT-Projektverträgen geriert. Eine Vertragsgestaltung gegen diese Erwartung in vorformulierten Vertragsmustern für IT-Projektverträge dürfte in aller Regel überraschend und damit unwirksam sein.
3. IT-Projektverträge als Festpreisverträge
Das Werkvertragsrecht kennt sowohl Festpreisverträge als auch Verträge gegen eine aufwandabhängige Vergütung (Time&Material). Der Grundtyp des Werkvertragsrechts ist aber der Festpreisvertrag. Dieser verteilt das Risiko 100% zu 0% zu Lasten des Werkunternehmers. Wenn der Schreiner verspricht, den Schrank für 1000 EUR zu bauen, dann muss er den Schrank für 1000 EUR bauen, auch wenn sein Zeitaufwand wesentlich höher ist als er ihn eingeschätzt hatte. Gleiches gilt freilich, wenn eine Webseite zu einem Festpreis entwickelt werden soll. Der Anspruch auf Werklohn wird fällig, wenn der Auftraggeber es als „im Wesentlichen vertragsgemäß“ abnimmt oder die Abnahme zu Unrecht verweigert. Der IT-Dienstleister, der mit dem IT-Projekt beauftragt wurde, ist also ohne abweichende vertragliche Regelung nicht nur zur Vorleistung verpflichtet, sondern trägt auch das Risiko einer angemessenen Schätzung der Realisierbarkeit des IT-Projekts innerhalb der vereinbarten Zeit und dem vereinbarten Budget allein. Diese Risikoverteilung ist nur dann fair, wenn der IT-Dienstleister die mit dem IT-Projekt verbundenen Projektrisiken hinreichend gut kennt und diese in den Festpreis einpreisen kann. In dem früher im IT-Projektmanagement üblichen Wasserfallmodell hat man daher zweiphasig gearbeitet. In der ersten Phase wurde das Projekt geplant, in der zweiten Phase abgearbeitet. Die moderneren agilen Methoden des Management von IT- Projekten scheuen den Planungswasserkopf des Wasserfallmodells und haben diese zugunsten des agilen (iterativen) Vorgehens kürzerer zyklischer Wechsel von Planungs- und Entwicklungsphasen zum Fenster hinausgeworfen. Doch allein die Zwei- oder Mehrphasigkeit erlaubt es, bei der Gestaltung eines IT-Projektvertrags Sollbruchstellen in Form von Milestones in den Vertrag einzuführen, mit denen das Risiko zwischen den Parteien verteilt werden kann. Dass diese Sollbruchstelle nicht mehr Planungsphase heißt, sondern Machbarkeitsstudie, Kick-off-Projekt, Konzept- und Designphase oder ähnlich, ändert nichts daran, dass die Funktion bei der Gestaltung von IT-Projektverträgen dieselbe ist wie früher beim einem zweistufigen IT-Projektvertrag nach dem Wasserfallmodell. So kommt das im agilen Projektmanagement zum Fenster hinaus geworfene Wasserfallmodell bei der Vertragsgestaltung eines IT-Projektvertrags gleichsam zur Tür wieder herein.
4. IT-Projektverträge als Time-and-Material-Verträge mit Lock-in-Effekt für den Auftraggeber von IT-Projekten
So unbillig wie der Festpreisvertrag für den Auftragnehmer ist, so unbillig ist eine rein aufwandanhängige Vergütung für den Auftraggeber. Ohne klare Milestones mit definierten Zwischenergebnissen oder einer gestuften Vergütung, die zumindest einen Teil des Vergütungsanspruchs vom Projekterfolgt abhängig macht, ist der Auftraggeber dem Auftragnehmer auf Gedeih und Verderb ausgeliefert. Wenn der Auftragnehmer keine (Teil-) Ergebnis innerhalb eines verbindlichen Zeitziels und/oder innerhalb eines festen Budgets schuldet, kann der Auftraggeber wenig tun, wenn es immer teurer wird und es immer länger dauert. Er hat nur die Wahl zwischen zwei kaum zumutbaren Optionen: Entweder er bricht ab und verliert alles, was er bisher bezahlt hat oder er zahlt weiter und weiter und weiter. Der einzige Ausweg bietet der Rücktritt, der freilich eine Vertragsverletzung voraussetzt. Wer den Auftraggeber eines IT-Projekts in einer derart misslichen Lage als Anwalt berät, wird sich dann natürlich auf die Suche nach formalen Aspekten machen, den Vertrag zu beenden.
5. Meilensteine für IT-Projektverträge zur Quadratur des Kreises
Stellt man sich beim einem IT-Projektvertrag den Festpreis als Kreis vor und die aufwandabhängige Vergütung als Quadrat, so ist das Zweiphasenmodell vielleicht ein Sechseck. Es erlaubt immerhin, dass die Parteien das IT-Projekt an einem vertraglichen definierten Punkt evaluieren und entscheiden, ob sie weitermachen oder abbrechen wollen. Der vertragsgestaltende Anwalt kann zwar den Kreis nicht quadrieren, er kann aber im Prinzip auch aus ein Zweiphasenmodell (mit einem Meilenstein), ein Drei-, Vier-, Fünf- oder Sechsphasenmodell (mit zwei, drei, vier oder fünf Meilensteinen) gestalten und so das Risiko unvorhergesehener Ereignisse zwischen den Parteien auch differenziert verteilen. Die Vorleistungspflicht des Auftragnehmers kann durch Abschlagzahlungen gemildert werden. Dem Auftraggeber können Kündigungsrechte eingeräumt werden, wenn er nicht mehr an den Erfolg des IT-Projekts glaubt. Der Auftragnehmer kann für den Fall der Ausübung einer solchen Kündigung durch eine geringere Vergütung am Risiko des Scheiterns des IT-Projekts beteiligt werden. Alle diese Regelungen können zu unterschiedlichen Milestones an unterschiedliche Voraussetzungen geknüpft werden. Der Fantasie sind an dieser Stelle nur wenig Grenzen gesetzt. Wer ein IT-Projekt von einer gewissen Bedeutung plant, sollte das Risiko des Scheiterns in Betracht und durch vertraglich definierte Meilensteine mit Zwischenergebnissen dafür sorgen, dass das Projekt regelmäßig evaluiert und ein mögliches Scheitern so früh wie möglich sichtbar wird. Kündigungsrechte und eine reduzierte Vergütung des Auftragnehmers im Falle des Projektabbruchs sorgen dann für eine ausgewogene Risikoverteilung.