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 Inter­essen der Parteien

a) Leistungs­umfang
b) Zeit und Budget

2. Lösung: Werkvertrag mit Projekt­ma­na­ge­ment­ver­ant­wortung beim Auftrag­nehmer und Mitwir­kungs­pflichten des Auftrag­gebers

II. Die Leistungsbeschreibung / Mitwirkung

1. Termi­no­logie und Verant­wort­lichkeit Lastenheft/Pflich­tenheft

a) Termi­no­logie
b) Lastenheft
c) Pflich­tenheft

2. Mitwirkung

a) Recht­liche Einordnung
b) Abruf
c) Prüfung und Zurück­weisung

3. Priori­sierung und Katego­ri­sierung zum Zweck des Manage­ments des Projekts

a) Priori­sierung der Anfor­de­rungen
b) Katego­ri­sierung der Mitwir­kungen

III. Projektmanagement

1. Pläne und Arbeit­s­pakete

a) Arbeit­s­pakete
b) Netzplan

2. Baseline, Toleranzen und Ausnahmen

3. Risiko­ma­na­gement

a) Mitwir­kungen
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 Inter­essen der Parteien

 

a) Leistungs­umfang

1

Unter­nehmen, die mit der Imple­men­tierung von Anfor­de­rungen in eine nicht von ihnen entwi­ckelte Standard­software beauf­tragt werden, verstehen sich als „IT-Beratungs­häuser“1. Nach ihrer Vorstellung erbringen sie Dienst­leis­tungen; die Verantwortung für den Erfolg des Projekts trägt allein der Auftrag­geber.

2

Grundlage dieser Erwar­tungs­haltung sind Unsicher­heiten in Bezug auf den Leistungs­umfang und die Mitwir­kungs­fä­higkeit des Auftrag­gebers. Die Funktio­na­lität einer Standard­software bildet die Best Practices von Unter­neh­men­spro­zessen ab, die durch Parame­trierung an die Anfor­de­rungen eines konkreten Unter­nehmens angepasst werden können. Für die Parame­trierung gibt es ebenfalls Best Practices. Der Auftrag­nehmer weiß in der Regel nicht, ob der Auftrag­geber mit den in der Standard­software abgebil­deten Best Practices arbeiten kann oder möchte, und er kennt die von den Best Practices abwei­chenden Prozesse des Auftrag­gebers nicht. In umfang­reichen Projekten wird daher oftmals der eigent­lichen Imple­men­tierung eine sog. Blueprint-Phase vorge­schaltet, in der die Parteien inter­aktiv in gemein­samen Workshops die Grund­lagen für die Parame­trierung erarbeiten. Erst danach kann der Auftrag­nehmer den Leistungs­umfang einschätzen.

3

Auftrag­geber unter­schätzen häufig die von ihnen zu erbrin­gende Mitwirkung im Projekt2. Das betrifft nicht nur den Reifegrad der eigenen Organi­sation, sondern auch die Verän­de­rungs­angst der Mitar­beiter. So hängt der Erfolg eines IT-Projekts auch davon ab, ob das Projekt von allen Mitar­beitern des Auftrag­gebers unter­stützt wird, oder ob es beim Auftrag­geber einzelne Mitar­beiter gibt, die das Projekt nicht nur nicht unter­stützen, etwa weil sie von dem Softwa­re­produkt nicht überzeugt sind, sondern ggf. sogar gezielt behindern, etwa weil sie befürchten, dass die Software künftig einen Teil ihrer bishe­rigen manuellen Arbeit erledigt und sie insoweit überflüssig werden. Der Auftrag­nehmer, der keinen Einblick in derartige Befind­lich­keiten der Mitar­beiter des Auftrag­gebers hat, möchte für deren Folgen verständ­li­cher­weise nicht die Verant­wortung übernehmen.

4

Auftrag­geber, die eine neue Software einführen wollen, kennen wiederum weder die darin vorge­se­henen Best Practices im Detail, noch haben sie ausrei­chende Kennt­nisse in Bezug auf die Software selbst. Sie vertrauen auf das oft beworbene, umfas­sende Know-how der IT-Unter­nehmen und auf deren Fähigkeit, alle ihre unter­neh­mensin­ternen Prozesse durch Custo­mizing und Program­mierung in die vertrags­ge­gen­ständ­liche Standard­software wunsch­gemäß zu imple­men­tieren. Diese Haltung ist im Grundsatz auch legitim, denn die Recht­spre­chung hat Auftrag­nehmern Beratungs- und Hinweis­pflichten auferlegt, deren Verletzung einen Schadenser­satz­an­spruch des Auftrag­gebers zur Folge hat3. Nach der Vorstellung der Auftrag­geber erstellt der Auftrag­nehmer ein Werk und verant­wortet die erfolg­reiche Durch­führung des Projekts.

 

b) Zeit und Budget

5

Das Markt­for­schungs­in­stitut 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 beste­hende Betrieb finan­ziert werden. Ein erhöhtes Maß an Digita­li­sie­rungs­druck zwingt zum Umdenken von der Frage, wieviel IT finan­ziert wird, hin zu der Frage, wie die IT finan­ziert wird. Kosten­ma­na­gement ist mehr gefragt denn je. Mit der Einführung neuer Software wird eine Gewinn­stei­gerung angestrebt. Jede Verzö­gerung kostet Geld. Die Verant­wortung für die Parameter time/budget legt der Auftrag­geber gerne in die Hände des Auftrag­nehmers. Festpreis und strenge Verzugs­regeln zwingen Auftrag­nehmer jedoch, einen Risiko­auf­schlag zu fordern. Den wahren Inter­essen des Auftrag­gebers wird auch das nicht gerecht.

6

Tatsächlich ist es nicht nur im Interesse des Auftrag­gebers, dass  (...)

Hier direkt weiterlesen im juris PartnerModul IT-Recht



Verlag Dr. Otto Schmidt vom 11.03.2021 11:31

zurück zur vorherigen Seite