Bei großen Entwicklungsprojekten – zum Beispiel der Programmierung eines Webshops – kommt es immer wieder zu Schieflagen, die es zu beheben gilt. Bei derlei Problemen herrscht meist zwischen Auftraggeber und Auftragnehmer Streit über die Erbringung des Leistungsergebnisses. Häufig geht es um verspätete Leistungen mit minderer oder auch fehlender Qualität.

Weitermachen oder aufgeben?

Nun kommt es entscheidend darauf an, die richtigen Maßnahmen zu ergreifen, um entweder ein Projekt noch zu einem erfolgreichen Ende zu führen oder es schnell zu beenden. Die letztgenannte Alternative ist für alle Beteiligten immer die schlechteste: Dem Auftragnehmer bringt sie in der Regel wirtschaftliche Verluste und der Auftraggeber hat nicht nur das mit der Durchführung des Projekts verfolgte Ziel nicht erreicht, er muss obendrein komplett ein neues Projekt ausschreiben, verhandeln und umsetzen.

Doch es gelingt auch immer wieder, Projekte – sogar bei wechselseitig fristlos gekündigten Verträgen und Androhung von einstweiligen Verfügungen – durch gut vorbereitete, nicht selten länger dauernde Verhandlungen wieder „aufs Gleis“ zu setzen. Wichtig ist dann, durch eine Zusatzvereinbarung neben rechtlichen Aspekten Maßnahmen zu definieren, um bekannte Fehler zu vermeiden.

Lastenheft und Pflichtenheft

Um solchen Projektschieflagen vorzubeugen, ist es im Rahmen des Vertragsschlusses für den Auftraggeber von Bedeutung, eine differenzierte Leistungsbeschreibung vorzusehen, die zumindest ein Lastenheft („Was wofür?“) mit einer fachlichen Grobkonzeption nebst vollständigen Funktionen und Anforderungen aufweist. Noch besser ist ein Pflichtenheft („Wie womit?“), das neben der fachlichen Feinspezifikation bereits eine technische Konzeption enthält.

Über die Definition funktionaler Spezifikationen hinaus sollte auch eine Festlegung der nicht funktionalen Anforderungen festgeschrieben werden. „Nicht funktional“ ist zum Beispiel das Antwortverhalten einer Website.Reagiert die Webseite eines Online Shops mit einer Verzögerung von drei Sekunden, sind Abbrüche und damit der fehlende Erfolg des Online Shops genauso programmiert wie eine Projekteskalation.

Auf der anderen Seite sollte der Auftragnehmer dezidiert definieren, welche Mitwirkungsverpflichtungen der Kunde zu erbringen hat. Da IT-Projekte meistens zeitkritisch sind, sollte darüber hinaus zwischen den Vertragsparteien ein verbindlicher Meilensteinplan vereinbart werden, der bei Überschreitung zu Konsequenzen führt. Ein Meilenstein kann etwa die Übergabe einer Betaversion des Shops sein, ein weiterer Meilenstein das Ende einer Testphase dieser Betaversion durch den Kunden.

Zu Projektschieflagen kommt es üblicherweise dann, wenn es an einer klaren Ausarbeitung der wechselseitigen Verpflichtungen fehlt und der Auftragnehmer eine in den Augen des Auftraggebers mangelhafte Leistung (verspätet) abliefert. Danach setzt der Auftraggeber eine Frist und droht Konsequenzen an. Der Auftragnehmer dagegen verteidigt sich damit, dass der Auftraggeber seinen Mitwirkungspflichten weder in der entsprechenden Qualität noch rechtzeitig genügt hat.

Pattsituation führt zum Kippen

Die Vertragsparteien stehen sich somit in einer Pattsituation – der Projektschieflage – gegenüber, deren Eskalation zum Kippen des Projekts führt. Vor Gericht gewinnt meist derjenige mit den besseren vertraglichen Regelungen und der besseren Dokumentation des Projektverlaufs.Kann etwa ein Auftragnehmer durch E-Mails belegen, dass er immer wieder auf fehlende Mitwirkungspflichten und den daraus resultierenden Zeitverzug hingewiesen hat, wird ihm kaum ein Verschulden nachzuweisen sein.

Insbesondere bei großen Projekten geht es um Personen, die den Projekterfolg auch unternehmensintern zu vertreten haben, sodass Verhandlungen zur Auflösung solcher Projektschieflagen auch immer deren Gesichtswahrung zu berücksichtigen haben. Da der Streit sich meist auf die Qualität der erbrachten Leistung bezieht, kann es ratsam sein, einen EDV-Sachverständigen zur Bewertung einzusetzen. Aus kaufmännischer Sicht kann dieser Aufwand sinnvoll sein, da auch im Rahmen einer prozessualen Auseinandersetzung das Gericht auf Basis eines Sachverständigengutachtens entscheidet.

Im Vertrag an Schlichtung denken

Ein solches Schlichtungsverfahren kann bereits im Vertrag vorgesehen werden.Die Erfahrung zeigt, dass Projektschieflagen auch dadurch entstehen, dass die Vertragsparteien zu wenig miteinander kommunizieren. Empfehlenswert ist es daher, in Verträgen Regelungen über „IT/Project Governance“ und „Reporting“ einzuplanen, deren Ziel es ist, auf den verschiedenen Projektebenen in regelmäßigen Zyklen den Projektstatus zu kennen, um Risiken entgegenzuwirken. Gleichzeitig sollte bei Streitigkeiten auf der operativen Projektebene eine kurzfristige Eskalation an das Senior-Management vorgesehen sein, um auch hier schnell Konflikte einer Lösung zuführen zu können.

Die Exit-Strategie

Problematisch für die Fortführung eines Projekts wird es aber, wenn entweder der Auftraggeber oder am Ende sogar ein Sachverständiger zu dem Ergebnis kommt, dass dem Auftragnehmer Fähigkeiten fehlen, ein Projekt erfolgreich zu Ende zu führen. Hier helfen entsprechend vertraglich normierte Exit-Rechte.

Selbst wenn sich der Auftraggeber für eine Vertragsbeendigung entscheidet, empfiehlt es sich für beide Vertragsparteien, professionell über die Vertragsbeendigung zu verhandeln. Neben kommerziellen Aspekten, wie etwa Schadensersatz, geht es auch um die Frage, ob ein Teil der Ergebnisse für einen neuen Dienstleister nutzbar ist, was bei proprietärer Software des Auftragnehmers ausscheidet. In der wirtschaftlichen Gesamtschau kann es für einen Auftragnehmer von Interesse sein, auf kommerzieller Ebene Zugeständnisse zu machen, dafür dann aber über den gesamten Projektausstieg eine Geheimhaltungsvereinbarung abzuschließen. Scheitert ein großes Softwareprojekt, schadet dies auch dem Image des Auftragnehmers.

Zur Vorbereitung eines solchen Exits empfiehlt es sich auftraggeberseitig bereits frühzeitig, oder das gesamte Projekt über, eine Dokumentation zu führen. Es ist vor allem sinnvoll, Protokolle über Sitzungen der einzelnen Projekthierarchien anzufertigen, um dann im Schadensersatzprozess dokumentieren zu können, wen ein Verschulden trifft.

Wie viel Aufwand hatte der Kunde?

Es hat sich bewährt, Projektaufwände des Personals zu dokumentieren. Der Auftraggeber kann unter Umständen nicht nur die Rückzahlung von geleisteten Anzahlungen oder Schadensersatz wegen Verzugs, sondern auch nutzlos auf das Projekt eingesetzte Personalkosten verlangen. In einer vom Autor vertretenen Klage sprach jüngst das OLG Frankfurt dem Auftraggeber 934 Tage à 485 Euro pro Tag zu. ❚

DR. HAJO RAUSCHHOFER