Die eigentlichen Gründe für einen Projektabbruch sind vielfältig. Schuld sind beispielsweise unrealistische Zeitvorgaben oder überdimensionierte Projektvolumina, möglicherweise auch fehlende Akzeptanz beim Auftraggeber, nicht ausgereifte Software, fehlendes Know-how oder Kommunikationsschwierigkeiten. Keineswegs selten liegt die Ursache des Scheiterns aber auch in einer unzureichenden Ausgestaltung der Projektverträge. Die folgenden zehn Punkte sollen dem Auftraggeber einen groben Leitfaden für die Vertragsverhandlungen an die Hand geben:
1. Eine präzise Leistungsbeschreibung ist das A und O.
Versäumnisse in der Planungsphase rächen sich später besonders bitter. Trotzdem kommt diese Phase aus Zeitgründen häufig zu kurz. Sie dient vordringlich dazu, eine Leistungsbeschreibung, meist Pflichtenheft genannt, zu erstellen. Eine präzise Leistungsbeschreibung ist von entscheidender Bedeutung für den Projekterfolg, weil sie die Anforderungen an das zu liefernde System definiert. Das bedeutet umgekehrt aber auch, dass der Auftraggeber nur die Leistungen verlangen kann, die im Pflichtenheft aufgeführt sind. Stellt er beispielsweise erst im Laufe des Projekts fest, dass eine von ihm als selbstverständlich vorausgesetzte Funktion oder Schnittstelle in der Leistungsbeschreibung nicht enthalten ist, so hat er auch keinen Anspruch auf Realisierung - zumindest nicht, ohne einen kostenpflichtigen Zusatzauftrag zu erteilen. Die Folgen sind höhere Kosten und vermeidbare Auseinandersetzungen zwischen den Vertragspartnern. Das ist für den Auftraggeber umso unangenehmer, als er sich nun in einer Situation der Abhängigkeit befindet, also eine deutlich schlechtere Verhandlungsposition hat als vor Beginn des Projekts. Das beauftragende Unternehmen besitzt oft nicht das nötige Know-how, um die gewünschten Leistungen zu beschreiben. Unter diesen Umständen kann es sinnvoll sein, den Auftragnehmer gegen gesonderte Vergütung mit der Erstellung zu beauftragen. Entscheiden sich die Vertragsparteien für diese Variante, sollte aber explizit vereinbart werden, dass die Leistungsbeschreibung durch den Auftraggeber freizugeben ist.
2. Festpreise schützen vor bösen Überraschungen.
Aus Gründen der Budgetsicherheit empfiehlt sich unbedingt die Vereinbarung eines Festpreises. Praktiziert wird häufig eine Vergütung nach Aufwand. Doch davon ist dem Auftraggeber dringend abzuraten, weil der tatsächliche Aufwand den geplanten meist überschreitet. Im diesem Fall trüge der Auftraggeber das ganze Risiko, während es bei Festpreisprojekten auf Seiten des Auftragnehmers liegt.
3. Nicht vereinbarte Termine lassen sich auch nicht einklagen.
Mit der eigentlichen Realisierung des IT-Systems ist erst zu beginnen, nachdem der Leistungsumfang vertraglich festgelegt wurde, also wenn die zu erbringende Leistung präzise definiert und freigegeben ist. Das klingt wie eine Selbstverständlichkeit, wird aber häufig missachtet. Spätestens zu Beginn der Realisierung sollten die Vertragsparteien feste Termine vereinbaren - sowohl für die Fertigstellung als auch für einzelne Projektschritte. Diese Termine sind verbindlich und werden in einem Projektplan festgehalten. Nur so hat der Auftraggeber rechtlichen Möglichkeiten, gegen einen Verzögerung des Projekts vorzugehen.
4. Wer jede Phase einzeln definiert, behält den Überblick.
IT-Systeme werden häufig in Phasen oder "modular" eingeführt. Beispielsweise entsteht zunächst ein Prototyp, der Stufe für Stufe weiter ausgebaut wird. Idealerweise prüft der Auftraggeber jeden einzelnen Projektschritt und gibt ihn gesondert frei. Auf diese Weise bekommt das Vorhaben Struktur und gewinnt an Übersichtlichkeit. Dazu muss jedoch jede Phase einzeln definiert werden. Diese Vorgehensweise hat für den Auftraggeber - vor allem bei komplexen und langfristigen Vorhaben - einen entscheidenden Vorteil: Er ist in der Lage, den Projekterfolg laufend zu überwachen. Mit der Fertigstellung einer bestimmten Projektphase verbunden werden kann die Fälligkeit von Abschlagszahlungen. Doch auf keinen Fall sollte sich der Auftraggeber darauf einlassen, eine abgeschlossene Phase formal (teil-)abzunehmen. Das hat folgenden Grund: Die Verjährung seiner Mängelrechte für diese Phase würde bereits vor der Fertigstellung des Gesamtsystems beginnen.
5. Juristische Fallstricke lauern auch bei der Abnahme.
Der Auftraggeber sollte unbedingt darauf bestehen, das gelieferte Gesamtsystem abzunehmen. Vorher muss es einen Funktionstest absolvieren - und zwar für sämtliche Komponenten in ihrem Zusammenspiel. Diese Projektphase ist regelmäßig besonders kritisch: Mit der formalen Abnahme akzeptiert der Kunde das System als vertragsgemäß, wodurch die Fälligkeit der Vergütung oder zumindest der letzten Abschlagszahlung ausgelöst wird. Test- und Abnahmeprozedere - einschließlich der dafür gültigen Kriterien - sind deshalb ausführlich im Vertrag zu fixieren.
6. Änderungswünsche müssen geregelt werden.
Vor allem im Verlauf von komplexen und langwierigen IT-Projekten kommt es häufig zu Änderungswünschen des Auftraggebers - sei es aus technischen Gründen oder aufgrund von veränderten organisatorischen Rahmenbedingungen. Deshalb sollte der Projektvertrag detailliert regeln, wie mit solchen Änderungen umzugehen ist. Unter anderem muss er auf beiden Seiten konkrete Ansprechpartner für das Change-Request-Management benennen.
7. Der Auftraggeber hat ebenfalls Pflichten.
Eines wird gern übersehen: IT-Projekte erfordern meist die Mitwirkung des Auftraggebers. Sei es, dass der Anbieter Zugang zu dessen Gebäude erhält oder bestimmte Entscheidungen rechtzeitig in die Wege geleitet werden müssen. Manchmal liefert der Kunde auch umfangreiche Dokumentationen der vorhandenen IT-Infrastruktur, oder er übernimmt gar Teile der Projektarbeiten in Eigenregie. Wenn darüber keine Klarheit besteht, kommt es zwangsläufig zu Auseinandersetzungen. Deshalb sind Mitwirkungspflichten ausdrücklich und möglichst genau in den Vertrag aufzunehmen. Im Interesse des Auftraggebers liegt der Zusatz, dass die im Vertrag aufgeführten Mitwirkungen abschließend sind und es für ihn keine darüber hinaus gehenden Pflichten gibt.
8. Der Zugriff auf den Quellcode entzweit die Parteien.
Einen Konflikt löst häufig die Frage aus, ob, wann und wem der Source-Code ausgehändigt wird. Aus Sicht des Softwareanbieters repräsentiert das Quellprogramm das Kernstück seines Know-hows. Folglich ist der Auftragnehmer nur ungern bereit, es offenzulegen. Der Abnehmer hingegen benötigt diesen Code - einschließlich der Nutzungsrechte hieran - zumindest für den Fall, dass sein Vertragspartner die Software nicht mehr weiterentwickeln will oder kann. Das kommt vor allem dann vor, wenn der Anbieter Insolvenz beantragt. Im Kundeninteresse liegt deshalb eine rechtlich relevante Verpflichtung des Auftragnehmers, den Source-Code zu übergeben und regelmäßig zu aktualisieren sowie entsprechende Nutzungsrechte einzuräumen. Kann sich der Auftraggeber mit dieser Forderung bei den Vertragsverhandlungen nicht durchsetzen, gibt es eine Alternative: Denkbar ist hier der Abschluss einer Hinterlegungsvereinbarung (Escrow Agreement). Sie stellt sicher, dass unter bestimmten, vertraglich zu bestimmenden Voraussetzungen der Auftraggeber den Quellcode erhält.
9. Rechtzeitig an den Wartungsvertrag denken!
Ohne Weiterentwicklung (Updates) und dauernde Wartung wird das gelieferte IT-System für den Anwender schnell nutzlos. Auch hier hat der Lieferant also eine Pflicht, die ausdrücklich zu vereinbaren ist. Eine rechtliche Fixierung ist umso wichtiger, als Pflege und Wartung für einen IT-Anbieter eine enorm wichtige Einnahmequelle darstellen. Um einer überhöhten Vergütung vorzubeugen, sollte der Kunde den Wartungs- und Pflegevertrag zeitgleich mit der eigentlichen Projektvereinbarung schließen. Wenn er damit bis zum Abschluss der Realisierungsphase wartet, ist er seinem Lieferanten in gewissem Sinn ausgeliefert. Der Vertragsbeginn darf allerdings nicht auf ein bestimmtes Datum gelegt werden, er muss vielmehr von der Abnahme oder dem Ende der Gewährleistungsfrist für das gelieferte System abhängen.
10. Sanktionen in den Service Level Agreements sollen wehtun.
Im Wartungs- oder Pflegevertrag müssen konkrete Standards definiert sein sowie Sanktionen, die mit deren Nichteinhaltung verknüpft sind. Solche Service Level Agreements (SLAs) vereinbaren zum Beispiel durchschnittliche Verfügbarkeitsquoten beziehungsweise maximale Reaktions- und Fehlerbeseitigungszeiten. Werden sie überschritten, hat der Anbieter nach Dauer gestaffelte Vertragsstrafen zu entrichten. Aus Auftraggebersicht ist das vor allem dann sinnvoll, wenn die Vertragsstrafen so hoch ausfallen, dass sie den Auftragnehmer auch tatsächlich zur Einhaltung der definierten Standards antreiben.