in Erfolgskriterien, Konfliktmanagement, Vertragsgestaltung

Verträge sind oft die tiefere Ursache für das Scheitern von IT-Projekten

English version here/englische Version hier.

Große IT-Projekte können nicht ohne Mitwirkung externer Dienstleister abgewickelt werden. Natürlich benötigen die Beteiligten als Grundlage für die Beauftragung ein entsprechend ausführliches Vertragswerk.

Die Durchführung von detaillierten Vertragsverhandlungen hat einen unschätzbaren Vorteil. Die Arbeitsweise im Projekt wird gemeinsam durchgearbeitet, es werden Risikoszenarien diskutiert und darüber gesprochen, wie man diese bewältigen würde. Wenn man dies unterlässt, fehlt eine wichtige Phase des gegenseitigen Abtastens und Einander-Kennenlernens vor dem Start der eigentlichen Projektarbeit.

Vertragsinhalte müssen jedenfalls folgende Themen abdecken:

  • Ziel und Rahmenbedingungen
  • Ergebnisbeschreibung und Road-Map
  • Vorgehensmodell generell
  • Eingesetzte Tools für
    – Kollaboration und Dokumentation
    – Anforderungsdefinition, Entwicklung, Test, Betrieb
  • Lieferungen und Leistungen des Auftragnehmers
  • Mitwirkungsleistungen des Auftraggebers
  • Vergütung von Leistungen
  • Steuerung, Entscheidungen, Controlling
  • Konfliktregelung
  • Rechte und Pflichten der Vertragspartner  (vor, während und nach dem Projekt)
    – Sorgfalts-, Warn- und Hinweispflichten
    – Gewährleistung
    – Software-Wartung und -Support
    – Betrieb und Support.
Risikoüberwälzung geht oft nach hinten los

Da der Erfolg eines Projektes wesentlich von der Performance des externen Dienstleisters abhängt, ist das Bestreben, das Erfolgsrisiko durch Verträge auf diesen zu überwälzen, verständlich. Betrachtet man allerdings die finanzielle Leistungsfähigkeit eines solchen Unternehmens, so erkennt man, dass es eine relative geringe Kapitalausstattung hat. IT-Dienstleistungsunternehmen finanzieren sich über Deckungsbeiträge aus laufenden Umsätzen. Selbst große IT-Konzerne können Honorarminderungen nur in beschränktem Ausmaß kompensieren. Eine Haftung für Vermögensschäden durch entgangene Gewinne des Kunden übersteigt jedenfalls deren finanzielle Leistungsfähigkeit. Es würde auch kein großes Unternehmen einen Vertrag unterschreiben, der eine solche Verpflichtung beinhaltet.

Dies gilt umso mehr für kleinere IT-Dienstleister. Würde ein solches Unternehmen das Risiko eingehen, einen solchen Vertrag zu unterzeichnen, wäre bei Eintritt des Haftungsfalles der Konkurs die unausweichliche Folge. Eine Fortführung des Projektes wäre in diesem Fall nahezu unmöglich.

Aus diesem Grund schrecken die Auftraggeber selbst bei gravierenden Leistungsmängeln davor zurück, die volle Härte der Verträge in Anspruch zu nehmen. Harte Verträge, die zu Beginn zu Lasten des Auftragnehmers durchgesetzt werden, belasten häufig das Klima der Zusammenarbeit und erweisen sich im Ernstfall regelmäßig als zahnlos. Damit wird deutlich, dass der reale Schaden eines gescheiterten IT-Projektes für den Auftraggeber immer wesentlich höher ist als für den Auftragnehmer, egal wie die Vertragstexte dies darstellen.

Juristen kennen IT-Projekte aus einer spezifischen Perspektive

Die Vertragsgestaltung ist Sache der Juristen. Dabei gibt es ein grundsätzliches Problem. Juristen kennen Projekte nur aus Vertragsverhandlungen und haben selten mit der normalen Projektabwicklung zu tun. Erst wenn Projekte scheitern und vielleicht sogar vor Gericht landen, kommen die Juristen wieder ins Spiel. In einer solchen Situation, in der eine Fortführung des Projekts ohnehin ausgeschlossen ist, sind „harte“ Vertragsklauseln viel wert. Es ist daher nur natürlich, dass Juristen auf harte Absicherungsformulierungen achten, z.B. Vertragsstrafen und Haftungsbestimmungen. Diese Regelungen spielen bei einem einigermaßen gut laufenden Projekt keine Rolle. Sie stören auch nicht.

Wenn es bei einem gescheiterten Projekt nur noch um finanzielle Schadensbegrenzung geht, kann man aus solchen Klauseln je nach Bonität des Auftragnehmers zumindest eine gewisse Schadensminderung herausholen. Eine gerichtliche Auseinandersetzung wird gescheut, da die Schuldfrage nur durch eine Reihe von teuren, zeitaufwendigen und in ihren Aussagen nicht vorhersehbaren Gutachten geklärt werden kann. Daher enden solche Streitigkeiten meist mit einem außergerichtlichen Vergleich. Der Schaden des Auftraggebers ist dabei regelmäßig weit höher als das, was in der Praxis durch Vertragsstrafen und Haftungsansprüche erreicht werden kann. Je härter aber die Vertragsklauseln zugunsten des Auftraggebers formuliert sind, desto besser sind die Karten bei Vergleichsverhandlungen.

Auswirkungen der Verträge auf den Projektverlauf

Wenden wir uns nun den Auswirkungen eines Vertrages auf den „normalen“ Projektverlauf zu. Je härter und bedrohlicher die Vertragsbestimmungen für den Auftragnehmer sind, desto mehr werden Projektmanager, Anwälte und Claim Manager beim Auftragnehmer von der Geschäftsleitung angewiesen, Bedrohungsszenarien mit aller Macht abzuwenden. Vorsorglich versuchen sie natürlich, die Zugeständnisse, die sie bei den Vertragsverhandlungen machen mussten, wieder auszugleichen. Die Chancen dafür stehen gut. Es gibt kein IT-Projekt, bei dem die zu Projektbeginn gegebenen Vorgaben und Rahmenbedingungen bis zum Projektende konstant bleiben.

Je genauer alles in den Vertragsverhandlungen festgelegt wurde, desto größer ist die Wahrscheinlichkeit, dass auf Seiten des Auftraggebers etwas passiert, was nicht den vertraglichen Regelungen entspricht. Ein Klassiker sind die Mitwirkungsleistungen des Auftraggebers. Diese sind immer erforderlich, je größer das Projekt, desto mehr. Je mehr Druck auf den Auftragnehmer in den Vertragsverhandlungen ausgeübt wird, desto mehr wird der Auftragnehmer darauf bestehen, auch die Mitwirkungsleistungen des Auftraggebers genau zu definieren. Dies ist für den Auftraggeber schwer abzulehnen. Sobald der erste Punkt aus dem Pflichtenkatalog des Auftraggebers nicht erfüllt wird, setzt ein Dominoeffekt ein.

Die Machtverhältnisse kehren sich im Verlauf eines IT-Projekts um

Ist der Auftraggeber bis zur Auftragsvergabe und auch noch in den ersten Monaten des Projektes der umworbene Kunde, dessen Entscheidungen zählen, so entwickelt sich mit zunehmendem Projektfortschritt eine Abhängigkeit des Auftraggebers von den mittlerweile mit der Materie vertrauten Mitarbeitern des externen Dienstleisters. Irgendwann ist der Punkt erreicht, an dem die größte Sorge des Auftraggebers darin besteht, dass diese Schlüsselpersonen nicht mehr zur Verfügung stehen. Während in anderen Branchen, z.B. im Baugewerbe, die Austauschbarkeit der Dienstleister hoch ist, ist dies bei IT-Projekten nicht der Fall.

Die externen Mitarbeiter sind nach relativ kurzer Zeit mit den Details besser vertraut als die Mitarbeiter des Auftraggebers. Zum einen deswegen, weil es sich im Regelfall um hoch qualifizierte und hoch motivierte Leute handelt, und zum anderen, weil sie nicht im Tagesgeschäft verfangen sind. Sie erwerben daher sehr schnell solide Kenntnisse der Anforderungen. Aufgrund ihrer Routine und Fokussierung sind sie schnell mit der Materie vertraut und bald wissen sie darüber mehr als ein durchschnittlicher Sachbearbeiter.

Der Auftraggeber ist daher darauf angewiesen, dass der Auftragnehmer sein Schlüsselpersonal nicht abzieht. Diese Personen, die als Know-how-Träger umso wichtiger sind, je weniger Mitwirkungsleistungen der Auftraggeber akzeptiert hat, werden schließlich zu Assen im Machtspiel zwischen den Vertragsparteien. Ist diese Spirale erst einmal in Gang gesetzt, folgt das dicke Ende meist auf dem Fuß. Neue Vertragsverhandlungen, jetzt unter deutlich schlechteren Voraussetzungen für den Auftraggeber, der mit dem Rücken zu Wand steht, regeln die Fortführung des Projektes. Immerhin kann dieses nun zu Ende gebracht werden, es wird insgesamt später fertig als geplant und es wird auch teurer. Dass genau die „großartigen“ Vertragsbestimmungen zu Beginn die Probleme deutlich verschlimmert haben, ist nicht offensichtlich. Es will zu diesem Zeitpunkt auch niemand hören. Es ist auch vernünftig, jetzt keine Diskussionen über Vergangenes zu führen.

Wie sollen Verträge gestaltet werden?

Wenn die Beteiligten also Verträge erarbeiten, so sollten sie sich auf eine produktive Zusammenarbeit ausrichten und deren Modalitäten regeln. So unbefriedigend es auch ist, wenn kein Fixpreis vereinbart werden kann, so ist doch die Vereinbarung eines Verfahrens zur Preisermittlung und zum Umgang mit erkannten Mehraufwänden der vernünftigere Ansatz.

Es gibt IT-Projekte, bei denen eine Fixpreisvereinbarung möglich und sinnvoll ist. Das gilt für den Betrieb eines Rechenzentrums, für die Installation von Hardware und Standardsoftware oder auch für die Abwicklung von Help-Lines. Dort können auch Pönalen so definiert werden, dass sie eine steuernde Wirkung auf die Leistungen des Auftragnehmers haben. Es ist nur gefährlich, ein wirksames Werkzeug am falschen Objekt anzuwenden.

Verträge müssen eine konstruktive und produktive Zusammenarbeit ermöglichen. Wenn ein Projekt gut läuft, dann schaut man allenfalls in den Vertrag im Sinne von „Was haben wir dazu vereinbart? – Aha, dann machen wir es so!“

Es bringt dem Auftraggeber mehr, auf das wirtschaftliche Interesse des Auftragnehmers an einem gelungenen Projekt zu setzen als auf Pönalen und Haftungen für den Fall des Misslingens. Dafür ist allerdings erforderlich, die Arbeitsweise eines agilen Projektes zu verstehen und entsprechend zu handeln.

Agile Projekte – der Albtraum klassischer Vertragsgestalter

Generell beweisen die Zahlen der Standish Group, dass vor allem große IT-Projekte mit einem agilen Vorgehensmodell deutlich bessere Chancen auf Erfolg haben. Während das Handwerkszeug eines klassischen Werkvertrages als allseits bekannt vorausgesetzt werden kann, ist die Vertragsgestaltung für agile Projekte noch nicht Allgemeingut. Wird in Projektaufträgen bzw. in Verträgen eine Philosophie der Projektsteuerung festgeschrieben, die einer agilen Vorgehensweise widerspricht, geraten die Vertragspartner entweder in einen vertragsfreien Raum oder sie kollidieren ständig mit Vertragsbestimmungen, die nicht zum tatsächlichen Vorgehen passen.

Generell beruht agile Softwareentwicklung im Kern auf einer Aufwandsverrechnung, da ein fixer Werklohn mangels detaillierter Ergebnisbeschreibung nicht definiert werden kann. Die daraus resultierende Unschärfe wird von allen Beteiligten regelmäßig stark überschätzt: Dabei weiß jeder aus eigener Erfahrung, dass Fixpreise durch Change Requests regelmäßig ausgehebelt werden. Daher ist eine Aufwandsschätzung mit eingestandener Bandbreite sowie einer darauf aufsetzenden Projektsteuerung durch Burn-Down-Charts die ehrlichere und de facto auch wirksamere Methode. Man muss allerdings der hier sichtbar gemachten Unsicherheit ins Auge blicken können, wozu nicht alle Auftraggeber bereit und in der Lage sind. Dies gilt umso mehr, wenn die Umsetzung nicht durch die unternehmenseigene IT-Abteilung erfolgt, sondern durch ein externes Unternehmen.

Die zentrale Herausforderung kann so formuliert werden: Professionelle Projektsteuerung ersetzt detaillierte Ergebnisdefinition. Abweichungen werden so früher erkannt als in klassischen Projekten. Damit das funktioniert, müssen geeignete Prozesse (auch vertraglich) definiert und gelebt werden. Agile Projekte erfordern mehr Projektmanagement-Skills, vor allem aufseiten des Kunden.

Agile Projekte können daher nur gelingen, wenn es aktive und sachkundige Mitwirkungsleistungen des Kunden gibt. Im Falle einer externen Beauftragung gilt dies nicht nur für die Anwenderbereiche („Business“), sondern auch für die IT-Abteilung des Auftraggebers. Diese durchgängigen Mitwirkungsleistungen erscheinen gegenüber einem Wasserfallmodell als Mehraufwand. Ob man diese Ersparnis in späteren Projektphasen durch Nachbesserungen wieder verliert, weiß man zu Beginn nicht. Meine eigene Erfahrung und die aller agil arbeitenden Projektmanager zeigt, dass der tatsächliche Gesamtaufwand gut gemanagter agiler Projekte deutlich geringer ist als der eines klassischen Projektes gemäß einem Wasserfallmodell. Allerdings ist der Aufwand anders verteilt, nämlich über die gesamte Laufzeit ziemlich gleichmäßig. Zu Fragen des Aufwandes habe ich in Kapitel 4 meines Buches ausführlicher Stellung genommen.

Ebenso gilt: Agiles Vorgehen erfordert vertrauensvolle Zusammenarbeit. Dafür müssen Bereitschaft und Fähigkeit zu interdisziplinärer Arbeit und Social Skills bei allen Beteiligten verfügbar sein.

Was ist der wirklich entscheidende Erfolgsfaktor für agile IT-Projekte?

Nach meiner Erfahrung ist das Vertrauen in die Angemessenheit der Aufwände des Realisierungspartners ein entscheidender Erfolgsfaktor. Das Aushandeln des Verzichts auf Features, um das Budget und den Endtermin zu halten, funktioniert nur, wenn die vom Auftragnehmer geschätzten Realisierungsaufwände vom Auftraggeber als angemessen und nachvollziehbar gesehen werden. Regelmäßig als überhöht empfundene Aufwandsschätzungen können auf Architekturmängel zurückzuführen und daher in Wirklichkeit angemessen sein. In der Praxis werden diese allerdings meist als Indikator für eine unfaire Preisgestaltung des Auftragnehmers interpretiert, führen zu Konflikten, gegenseitigen Vorwürfen und Schuldzuweisungen. Diese können, wenn überhaupt, nur durch externe Expertise oder – der häufigere Fall – Resignation des Auftraggebers angesichts der Ausweglosigkeit einer Trennung vom aktuellen Auftragnehmer gelöst werden.

Werkverträge funktionieren nicht mehr – es braucht ein neues Paradigma

Das Vertragsmodell muss vom Ideal des Werkvertrages (transaktionaler Vertragstyp: Definition eines zu erstellenden Werkes zu einem vorab fixierten Preis) abgehen und „relationale Verträge“ implementieren. Solche Verträge regeln die Zusammenarbeit. Teil der Vereinbarungen ist das Vorgehen zur Festlegung des angestrebten Ergebnisses und der damit verbundenen finanziellen Transaktionen.

Ein Autorenteam rund um den Nobelpreisträger Oliver Hart hat im Harvard Business Review (September/Oktober 2019) diesen Paradigmenwechsel so beschrieben:

  • Traditionelle Kaufverträge funktionieren nicht in komplexen strategischen Beziehungen, wo die Parteien in hohem Maße voneinander abhängig sind, künftige Ereignisse nicht vorhergesagt werden können und Flexibilität und Vertrauen notwendig sind. Anstatt die partnerschaftlichen Beziehungen, die zur Bewältigung dieser Herausforderungen notwendig sind, zu fördern, unterminieren traditionelle Verträge diese.
  • Ein relationaler Vertrag schafft die Grundlagen für Vertrauen, definiert die beiderseitigen Ziele und etabliert Governance-Strukturen, um die Erwartungen und Interessen der Parteien über die Zeit zu harmonisieren.
  • Relationale Verträge werden niemals vollständig traditionelle transaktionale Verträge ersetzen und sollen das auch nicht. Aber der Prozess zur Vereinbarung eines relationalen Vertrages sollte Teil des Werkzeugkastens zur Vertragserstellung sein, um hoch komplexe Beziehungen zu regeln, die Zusammenarbeit und Flexibilität erfordern.

IT-Projekte erfüllen heute ab einer gewissen Größenordnung genau die von Hart u. a. genannten Voraussetzungen. Es ist also nicht verwunderlich, dass sie durch die Anwendung von traditionellen Vertragsmodellen so häufig scheitern. Karl Kraus hat einst gemeint, die Psychoanalyse sei die Krankheit, für deren Heilung sie sich hält. Ich meine, so etwas kann man mit Recht über viele Verträge sagen, die den Erfolg eines IT-Projektes absichern sollen.

Schreibe einen Kommentar

Kommentar