Aktuell in der CR
Vertragsklausel im IT-Projektmanagement (Heydn/Schultz, CR 2021, 145)Dieser Beitrag stellt – beispielhaft für einen Vertrag zur Implementierung von Kundenanforderungen in eine nicht vom Auftragnehmer hergestellte Standardsoftware bei einem großen Unternehmen – die wichtigsten Aspekte zur vertraglichen Verknüpfung von Recht und Projektmanagement zum Zweck der bestmöglichen Projektzielerreichung dar. Dabei gehen die Verfasserinnen zunächst auf die Frage ein, welcher Vertragstyp geeignet ist, um den Interessen der Parteien Rechnung zu tragen (I.), setzen sich dann mit Aspekten zum Leistungsumfang und zu den Mitwirkungen auseinander (II.), um dann aufzuzeigen, wie der Vertrag die Projektmanager bei einer effizienten Bewältigung ihrer Aufgabe unterstützen kann (III). Die dargestellten Probleme treten in der Praxis zumeist bei umfangreichen Implementierungsprojekten in großen Unternehmen mit fünf- oder sechsstelligen Mitarbeiterzahlen auf. Die Prinzipien für ein erfolgreiches Projektmanagement gelten für alle IT-Projekte; die vorgeschlagenen Klauseln sind bei kleineren Projekten jedoch anzupassen.
Zentrale Weichenstellungen
INHALTSVERZEICHNIS:
I. Vertragstyp
1. Die Interessen der Parteien
a) Leistungsumfang
b) Zeit und Budget
2. Lösung: Werkvertrag mit Projektmanagementverantwortung beim Auftragnehmer und Mitwirkungspflichten des Auftraggebers
II. Die Leistungsbeschreibung / Mitwirkung
1. Terminologie und Verantwortlichkeit Lastenheft/Pflichtenheft
a) Terminologie
b) Lastenheft
c) Pflichtenheft
2. Mitwirkung
a) Rechtliche Einordnung
b) Abruf
c) Prüfung und Zurückweisung
3. Priorisierung und Kategorisierung zum Zweck des Managements des Projekts
a) Priorisierung der Anforderungen
b) Kategorisierung der Mitwirkungen
III. Projektmanagement
1. Pläne und Arbeitspakete
a) Arbeitspakete
b) Netzplan
2. Baseline, Toleranzen und Ausnahmen
3. Risikomanagement
a) Mitwirkungen
b) Time/Budget
c) Weitere Bereiche
IV. Fazit
In den vergangenen Jahren wurde das Scheitern von IT-Projekten in diversen Studien untersucht. Dabei wurde festgestellt, dass ca. 20 % aller IT-Projekte abgebrochen und nur weniger als 50 % erfolgreich abgeschlossen werden. Sie scheitern an mangelhafter Kommunikation in Bezug auf die Leistungsbeschreibung und in Bezug auf die Mitwirkungen und damit letztlich am Business Case. Die Aufwendungen in Form von Zeit und/oder Geld, die notwendig werden, um die Qualität des Endprodukts zu sichern, sind mitten im Projekt nicht mehr zu rechtfertigen.
Daher ist es nicht nur zwingend erforderlich, den Leistungsumfang mit den korrespondierenden Mitwirkungen vertraglich festzulegen. Die Verfasserinnen haben in ihrer langjährigen juristischen Begleitung und Aufarbeitung von IT-Projekten die Erfahrung gemacht, dass der Vertragsinhalt ein Schlüssel zu erfolgreichen Projekten sein kann, wenn er sich nicht nur auf die Vereinbarung von Zeit und Kosten beschränkt, sondern darüber hinaus auch Mechanismen zum Umgang mit Volatilität in Bezug auf Leistungsumfang und Mitwirkungen und zum Umgang mit den in Zielkonkurrenz damit stehenden Parametern Zeit und Kosten („Magisches Dreieck“ im Projektmanagement: Scope/Time/Budget) enthält. Das gelingt sowohl in klassischen Wasserfall‑, als auch in iterativen (agilen) oder hybriden Projekten. Wurde dies versäumt, hilft oft nur noch eine praxistaugliche Kündigungsklausel – die notwendiger Bestandteil eines jeden IT-Projektvertrages ist.
|
I. Vertragstyp |
|
1. Die Interessen der Parteien |
|
a) Leistungsumfang |
1 |
Unternehmen, die mit der Implementierung von Anforderungen in eine nicht von ihnen entwickelte Standardsoftware beauftragt werden, verstehen sich als „IT-Beratungshäuser“1. Nach ihrer Vorstellung erbringen sie Dienstleistungen; die Verantwortung für den Erfolg des Projekts trägt allein der Auftraggeber. |
2 |
Grundlage dieser Erwartungshaltung sind Unsicherheiten in Bezug auf den Leistungsumfang und die Mitwirkungsfähigkeit des Auftraggebers. Die Funktionalität einer Standardsoftware bildet die Best Practices von Unternehmensprozessen ab, die durch Parametrierung an die Anforderungen eines konkreten Unternehmens angepasst werden können. Für die Parametrierung gibt es ebenfalls Best Practices. Der Auftragnehmer weiß in der Regel nicht, ob der Auftraggeber mit den in der Standardsoftware abgebildeten Best Practices arbeiten kann oder möchte, und er kennt die von den Best Practices abweichenden Prozesse des Auftraggebers nicht. In umfangreichen Projekten wird daher oftmals der eigentlichen Implementierung eine sog. Blueprint-Phase vorgeschaltet, in der die Parteien interaktiv in gemeinsamen Workshops die Grundlagen für die Parametrierung erarbeiten. Erst danach kann der Auftragnehmer den Leistungsumfang einschätzen. |
3 |
Auftraggeber unterschätzen häufig die von ihnen zu erbringende Mitwirkung im Projekt2. Das betrifft nicht nur den Reifegrad der eigenen Organisation, sondern auch die Veränderungsangst der Mitarbeiter. So hängt der Erfolg eines IT-Projekts auch davon ab, ob das Projekt von allen Mitarbeitern des Auftraggebers unterstützt wird, oder ob es beim Auftraggeber einzelne Mitarbeiter gibt, die das Projekt nicht nur nicht unterstützen, etwa weil sie von dem Softwareprodukt nicht überzeugt sind, sondern ggf. sogar gezielt behindern, etwa weil sie befürchten, dass die Software künftig einen Teil ihrer bisherigen manuellen Arbeit erledigt und sie insoweit überflüssig werden. Der Auftragnehmer, der keinen Einblick in derartige Befindlichkeiten der Mitarbeiter des Auftraggebers hat, möchte für deren Folgen verständlicherweise nicht die Verantwortung übernehmen. |
4 |
Auftraggeber, die eine neue Software einführen wollen, kennen wiederum weder die darin vorgesehenen Best Practices im Detail, noch haben sie ausreichende Kenntnisse in Bezug auf die Software selbst. Sie vertrauen auf das oft beworbene, umfassende Know-how der IT-Unternehmen und auf deren Fähigkeit, alle ihre unternehmensinternen Prozesse durch Customizing und Programmierung in die vertragsgegenständliche Standardsoftware wunschgemäß zu implementieren. Diese Haltung ist im Grundsatz auch legitim, denn die Rechtsprechung hat Auftragnehmern Beratungs- und Hinweispflichten auferlegt, deren Verletzung einen Schadensersatzanspruch des Auftraggebers zur Folge hat3. Nach der Vorstellung der Auftraggeber erstellt der Auftragnehmer ein Werk und verantwortet die erfolgreiche Durchführung des Projekts. |
|
b) Zeit und Budget |
5 |
Das Marktforschungsinstitut Gartner erwartet ein Wachstum der weltweiten IT-Ausgaben im Jahr 2021 um 6,1 %4. Mit dem in Summe wachsenden Budget muss jedoch nicht nur der bestehende Betrieb finanziert werden. Ein erhöhtes Maß an Digitalisierungsdruck zwingt zum Umdenken von der Frage, wieviel IT finanziert wird, hin zu der Frage, wie die IT finanziert wird. Kostenmanagement ist mehr gefragt denn je. Mit der Einführung neuer Software wird eine Gewinnsteigerung angestrebt. Jede Verzögerung kostet Geld. Die Verantwortung für die Parameter time/budget legt der Auftraggeber gerne in die Hände des Auftragnehmers. Festpreis und strenge Verzugsregeln zwingen Auftragnehmer jedoch, einen Risikoaufschlag zu fordern. Den wahren Interessen des Auftraggebers wird auch das nicht gerecht. |
6 |
Tatsächlich ist es nicht nur im Interesse des Auftraggebers, dass (...) |
Hier direkt weiterlesen im juris PartnerModul IT-Recht