Abschied von Festpreis und Pflichtenheft

Von: Dr. Werner H. Born

Scheitert ein IT-Projekt, stehen die Beteiligten häufig vor einem Scherbenhaufen. Die Vereinbarung eines Festpreises oder die Ausarbeitung eines Pflichtenheftes zu Projektbeginn führen in der Praxis oftmals nicht zum Erfolg. Dynamische Vertragsstrukturen bieten für beide Seiten Vorteile und erhöhen die Wahrscheinlichkeit eines erfolgreichen Projektabschlusses.

 Die Einführung einer Standardsoftware, die auf spezielle Bedürfnisse des Anwenders angepasst werden soll, ist nach wie vor ein Risikogeschäft. Nur 27 Prozent aller IT-Projekte werden erfolgreich abgeschlossen. Von den verbleibenden 73 Prozent der IT-Projekte werden 23 Prozent völlig abgebrochen. Im Übrigen werden die Kosten im Mittel um 100 Prozent und die Projektdauer um 200 Prozent überschritten.
Das Scheitern des Projektes könnte durch die exakte Ausarbeitung eines Pflichtenheftes vermieden werden. Dies ist aber häufig nicht bezahlbar und auch technisch kaum möglich. Denn Software ist dynamisch, da die betriebswirtschaftlichen Vorgänge im Unternehmen selbst dynamisch sind. So sind die in der Praxis vorkommenden Leistungsänderungen (Change Requests) und die Explosion der Kosten und der Zeitüberschreitungen letzten Endes die Konsequenz aus einer unzureichenden Spezifikation der Wünsche des Anwenders zu Projektbeginn. Der Zusammenhang zwischen Anforderungen auf der einen Seite und Kosten auf der anderen ist Anwendern wiederum nur schwer vermittelbar. Änderungen eines Leistungsumfangs, die der Anwender als gering einschätzt, können bezüglich der Softwarearchitektur oft gravierende Auswirkungen haben. Dabei kann die Zeit, die für ein Projekt veranschlagt wurde, nicht beliebig über Personalkräfte kompensiert werden.
Dementsprechend werden in kaum einem anderen Bereich so unspezifische Pflichtenhefte erstellt, wie bei IT-Projekten. Oft begnügt man sich mit schlagwortartigen Umschreibungen einer gewünschten Funktionalität. Der Streit um den Leistungsumfang ist damit unausweichlich.

Die kaufmännische Lösung = Festpreis?

In der Praxis haben viele Unternehmen diese Zusammenhänge schmerzhaft erfahren. Die Geschäftsführung, die den Einblick in die IT-Landschaft und Erforderlichkeit der Anpassungen nicht haben kann und auch nicht haben muss, sucht die Lösung daher in dem Festpreis- oder Pauschalpreisvertrag. So hofft man, der Falle des Entwicklungs- und Aufwandsprojektes und damit dem unkalkulierbaren Zeit- und Kostenrahmen zu entgehen. Fatal ist dieser Weg deshalb, da das den Pauschalpreis akzeptierende IT-Unternehmen wiederum die Lösung im Change Request Management sucht und behaupten wird, dieses oder jenes sei nicht im Leistungsumfang der Pauschalpreisabrede enthalten. Die Beweislast für die Vereinbarung einer bestimmten Sollbeschaffenheit trägt indes der Anwender, der jedoch aufgrund des unzureichenden Pflichtenheftes über kein Beweismittel verfügt.
Man braucht daher nicht viel Phantasie, um sich vorzustellen, dass das Scheitern des Projektes vorprogrammiert ist. Zu irgendeinem Zeitpunkt werden sich Projektsteuerung, Lenkungsausschuss, Eskalationsgremien, Schlichter, Gerichte und Schiedsgerichte damit beschäftigen, eine Lösung zu finden. Freilich meistens zu spät, denn dann sind Zeit, Geld und – das Wichtigste – Vertrauen verloren. Der Irrweg über den Pauschalpreis- oder Festpreisvertrag ist daher nach meiner Erfahrung in den meisten Fällen der Grundstein für das Scheitern eines IT-Projektes.

Wie gelangt man also erfolgreich vom Standard zur spezifischen Anwendungslösung? Die neuralgischen Punkte eines IT-Projektes – der Leistungsumfang, die Vergütung und die Zeit – müssen in ihrer Wechselwirkung beachtet werden. Es liegt in der Natur der Sache, dass zu Beginn eines IT-Projektes softwaretechnische Feinspezifikationen nicht vorliegen. Sie sind erst das Ergebnis einer intensiven Abstimmung zwischen Anwender und IT-Unternehmen. Steht der Leistungsumfang zu Vertragsbeginn aber nicht fest, können auch die Projektdauer und die Vergütung nicht feststehen. Das Spannungsverhältnis zwischen Pflichtenheft mit hohem Detaillierungsgrund und Pauschalpreis im Gegensatz zu dem Aufwandsprojekt lässt sich daher nur mittels dynamischer Vertragsstruktur lösen.

Der dynamische Projektvertrag weist keinen bestimmbaren Leistungsumfang auf, keinen bestimmbaren Zeithorizont und auch keinen bestimmbaren Kostenrahmen. Dies klingt im ersten Moment unannehmbar, da vermeintlich keine Planungssicherheit erreicht werden kann. Planungssicherheit wird aber nicht durch Verträge per se erreicht, sondern nur wenn Projektarbeit so gelebt wird, wie der Vertrag sie vorschreibt. Diese Projektregeln bilden den Nukleus des dynamischen Projektvertrages. Hier wird sich zeigen, wie konkret die Zielvorgaben des Anwenders sind, welche Qualifikationen die Mitarbeiter und Projektleiter auf beiden Seiten aufweisen und ob eine gemeinsame Sprache gefunden wurde, die im Rahmen der Kommunikation Defizite weitgehend ausschließt.

Der dynamische Projektvertrag

Fundament der dynamischen Vertragsstruktur ist die Prozessspezifikation. Sie beschreibt die Anwendungslösung für ein einzelnes Thema sowohl anwenderspezifisch als auch softwaretechnisch auf der Basis der Standardsoftware und der vom Anwender mitgeteilten Sollprozesse. Die Anzahl der Prozessspezifikationen ist dabei nicht beschränkt. Der Beauftragung zur Erstellung der Prozessspezifikation folgt dann die Beauftragung zur Realisierung der Prozessspezifikation auf der Grundlage der vom Anwender mitgeteilten Testdaten, Testszenarien und Anwendungsfälle. So kann nur die Prozessspezifikation selbst wieder eine genaue Aussage darüber treffen, innerhalb welchen Zeitrahmens die Anpassung durchgeführt werden kann und welche Vergütung hierfür anfallen wird. Letzten Endes ist nur die Prozessspezifikation damit die juristisch relevante Beschaffenheitsvereinbarung.

Durch die Atomisierung eines Pflichtenhefts in einzelne Prozessspezifikationen, die zeitlich versetzt parallel nach Vertragsschluss erstellt und abgearbeitet werden, wird somit eine Minimierung der typischen Risiken im IT-Projekt erzielt. Wird die erste Prozessspezifikation in der geplanten Zeit mit den vereinbarten Funktionalitäten realisiert, wird hierdurch Vertrauen für die zukünftigen Prozessspezifikationen aufgebaut. In rechtlicher und kaufmännischer Hinsicht ist damit der Abschluss eines Festpreis- oder Pauschalpreisvertrages obsolet geworden. Die wirtschaftlichen Risiken werden für beide Seiten auf die einzelne Prozessspezifikation begrenzt. Freilich kann durch den dynamischen Projektvertrag nicht das Risiko ausgeschlossen werden, dass das IT-Projekt teurer wird als ursprünglich geplant. Dies kann der Festpreisvertrag – wie die Praxis zeigt – aber ebenfalls nicht. Mit dem dynamischen Projektvertrag beginnt das mittelständische Unternehmen indes keine Fahrt ins Ungewisse, sondern erkennt frühzeitig, ob der richtige Softwarepartner gefunden wurde, oder ob das Projekt zur Vermeidung eines weiteren Verlustes an Zeit und Geld abgebrochen werden muss. Darüber hinaus kann zur Einhaltung eines internen Budgets jederzeit entschieden werden, ob die eine oder andere Funktionalität wirklich angepasst werden muss oder nur als schönes Beiwerk einzustufen ist, mit der Folge, dass man auf den Standard zurückgreift.